[sync] Turba and Syncml patch proposal

[Chuck Hagenbuch]

Quoting Karsten Fourmont <fourmont at gmx.de>:

> 1) turba has the already discussed "which source should I use" problem.
> I added an additional optional $source='' parameter to
> _turba_{import|delete|replace|export}. If $source is not specified
> $conf['client']['addressbook'] is used. This works fine for SyncML. The
> attached patch replaces my previous suggestion.

The client addressbook should *not* be used as the default. There is a
default_dir preference in Turba; that would be a reasonable default.

> 2) the _import functions now return a plain UID. However the history
> functions still require a "extended" guid like "memo:karsten:xxxx". This
> is a bit of a fracture: most API functions deal with plain UIDs, but
> when calling the /listBy Api function, I get an "extended" guid (as it
> comes from the datatree).

That should be fixed in the listBy functions, then.

> This is an issue for SyncML: after adding a
> new entry to the Horde Database, Syncml needs to get the log timestamp
> for that action. We need that as we have to manually remove these
> entries from /listBy results to avoid duplication by echoing back new
> entries to the client. However /import now returns only a plain guid and
> I can't feed this to the history object (for timestamp retrival) unless
> I add a prefix like 'turba:karsten:'. But this would be a bad solution:
> SyncML deals with the external API and only knows 'contacts', not 'turba'.

Why do you need the timestamp to filter out the uid?

> So what I did is this: History gets a getLastLoggedTS() functions that
> returns the timestamp of the last logged action. This value is stored in
> a global variable _lastLoggedTS and updated by
> DataTreeObject_History::log. See attached patch for History.php.
> Initially I tried to made _lastLoggedTS a member var of History, but for
> some reason even though History is a singleton, two instances are
> created (by the singleton function itself!) during a SyncML-run. Don't
> know why.
>
> Attached is a patch for History.php and the appropriate changes to
> SyncML. I also included a patch for turba's api (adding the source
> parameter, added missing functionality). Is it OK to commit this or is
> my history modification too bad a hack?

That is definitely too much of a hack; please don't commit it.

> Anyhow, IMHO the clean solution in the long run would be to expose the
> history through the external api:
>
> 1) somehow provide the timestamp of add/replace/delete operations. My
> suggestion: _import, _delete, _replace etc. should return an hash with
> lots of useful information (uid, timestamp, source for turba) instead of
> just the uid string.

getHistory() could be an API function as well. I'm not entirely opposed 
to your
suggestion of returning more info, but it seems less clean, API-wise.

> 2) the listBy API-Calls should provide similar information as well.
> Instead a simple array of GUIDs they should return an array
>     of hashes: key is the uid, values are ts,action,user,[source].

Again, I'm not entirely opposed to this but it seems less clean 
API-wise. But a
seperate "meta-info" fetching function doesn't seem that good either, so I can
be convinced - probably depends on how clean the implementation is.

-chuck

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