[sync] Turba and Syncml patch proposal

[Chuck Hagenbuch]

Quoting Karsten Fourmont <fourmont at gmx.de>:

>>> 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.
>
> OK. I can change this either in $history::getByTimestamp or just in the api
> listBy functions of the respective apps. I'd prefer the later: 
> history is used throughout horde, changes there would have a big 
> impact.

Yup, that's what I proposed too. :)

> So I propose to change the listby function in the api as follows. Instead of
> returning the extended guis with
>     return array_keys($histories);
> they'll return only the plain uid with something like
>
>     return preg_replace('/^([^:]*:){2}/', '', array_keys($histories));

Sounds good in theory; don't know off hand if that's the right implementation.
:)

> But now consider the next sync session. Here the reference period is 
> t_1 < t <
> t_2. The history call returns the client inducted modification X at t_s with
> t_1 < t_s < t_2 matching the reference period. The server can't know it came
> from the client orginially and so sends this as a modify request to 
> the client. This is wrong.
>
> So SyncML stores the timestamp for a client inducted change on the 
> server side
> in its internal map. So it can see if a specifig change came from the client
> and thus must not be sent back to the client.

Okay. I thought that this is what device ids were for, though?

> As I explained above, we do need a way to retrieve the timestamp of a given
> operation. So we'll go back to the old getTSForAction() way. But it's cleaner
> to have it in the api. So I'd like to add a new api function. Something like
>
> function getTSforAction($uid, $action)
> {
>     require_once 'Horde/History.php';
>     $history = &Horde_History::singleton();
>
>     $guid= 'turba:' . Auth::getAuth() . ':' . $uid;
>
>     return $history->getTSforAction($guid, $action);
> }
>
> same for kronolith and mnemo. Is the name OK? Maybe just "getTS"?

How about just getHistory($uid), for getting the history of that object? Then
you can get whatever information you need from the object's history. Seems a
little cleaner and more generally useful.

> 1) the external API only deals with plain uids. Not at all with 
> extended guids
> used and returned by the history functions

Yup.

> 2) SyncML does not directly call history anymore. Everything is just 
> done using the external API.

Yup.

> Some comments or a confirmation on that would be nice. Until that 
> I'll wait with the coding. I don't want a third patch proposal from 
> me getting blown to pieces :-) But I think it was worth the effort.

But they're productive pieces! Other things grow in them. ;)

I think this is shaping up nicely.

-chuck

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