[sync] Turba and Syncml patch proposal

[Chuck Hagenbuch]

Quoting Karsten Fourmont <fourmont at gmx.de>:

> lib/Driver.php:
> -fixes history to use logging guid  'turba:source:uid' rather than guid
> only.

See previous message, what I committed should be sufficient.

> -adds support for a few additional fields ("URL", "PAGER", name prefix)
> to turba/lib/Driver.php: tohash and tovcard

Sounds fine.

> lib/api.php
> -adds contenttype text/x-vcard support to turba_replace. Currently it
> supports only array.

Great.

> -turba_[replace|delete|export] now accept a guid as turba:source:guid
> string or as
>   $uid= array('addressbook' => 'source , 'contactId' => guid) array
>   Currently they do nothing (or just raise an pear_error)

See prior message, this unfortunately has to be done another way.

> -turba_[replace|delete|export] now all use __uid rather than __key for
> identifying the object

Sounds right.

> -turba_import now uses the default address book from the prefs if no
> source is specified.

Sounds okay.

>   If this doesn't work the first user writeable address book is used.

I'm not sure about this. We should probably return an error here to avoid
accidental writes.

> -turba_import returns a guid in turba:source:guid format

Should just return the UID.

> What I don't know is if the api is supposed to use the keys or the uids
>   and if the turba:source:uid form is still valid.

It should universally use UIDs, though it should have a method to turn a known
addressbook/key pair into a UID. And no to the 2nd question.

> My patch goes in the direction of using uids (not keys) in the format
> "turba:source:uid". I think that's consistent with the api.php of the
> other modules, only with the addition of the :source part to specify the
> address book.

I know some of this isn't consistent with other modules, but they need to be
updated too.

> I haven't found anyhting in the archive about the reasons for
> introducing seperate keys and uids and the "disabling" of turba_export.
> So if there's anything I missed, a few pointers would be great.

We need to store UIDs entirely seperately because we can't change them. 
If a uid
comes in as "foo", we need to keep it "foo" (and no, the syncml map can't do
this, because we need to handle uids from other sources, like iTip). Therefore
we can't guarantee any addressbook information will be in the UID in the first
place, we can't guarantee it'll match the key (because two users might 
have the
same calendar event in the same backend, but on different calendars, 
and we need
to treat them completely differently but still know they're linked). 
Etc. Ugly,
but all necessary to cleanly and consistently support all this.

> Is it Ok to commit this patch?

As Jan said, this needs to wait for Turba 2.0.1 at least (I'm personally okay
with saying the *turba* API isn't frozen, since these aren't big api changes
and the parts of the api most affected don't currently work anyway).

-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams