Good, I'm pleased you find my contributions useful.
However you only partially answered my question.
You explained that some devices natively support ADD/MODIFY/DELETE status,
and other devices only support ADD/MODIFY (indirectly via timestamps) and
yet others support none. But that is not my question.
My question (or rather my point) is this:
It is NOT necessary for the plugins to return the state (ADD/MODIFY/DELETE)
of each item to the sync-engine because the sync-engine is capable of
determining that itself by comparing the items it sees now with those
it saw before (at the previous synchronization).
So why ask the plugins to return that state info at all?
Currently, a plugin's get_changes() function must return the ADD/MODIFY/DELETE
state of each item on the device that has been modified since the last
synchronisation. That can be tricky, especially for the lesser capable
devices, and it makes the plugins all the more awkward to write.
I suggest a change to the plugin design to make them easier to develop:
Relax the requirements of the get_changes() function so it simply has to
return a verbatim copy of all items held in the device (regardless of state).
When the sync-engine calls this function, it determines the state of
each item returned from the plugin by comparing its UID with a list of UIDs
that it stored in a file at the previous synchronisation of the sync-pair.
The logic for determining an item's state is as follows:
If an incoming item's UID is NOT in the sync-pair's UID file
then its state is ADDED
else
its state must be either MODIFIED or UNALTERED.
These can then be distinguised by comparing the
revision date of the incoming item with the date of
the previson synchronisation (or by direct comparision
of the vcard data).
Lastly, any UIDs present in the sync-pair's UID file but omitted
from the list returned by the plugin are state DELETED.
Thus the sync-engine can releive the plugin of it state-tracking duties.
Remember too, the sync-engine already maintains a list of UIDs in the
sync-pair's ids file so it shouldnt require much change to the sync-engine.
Make sense?
Stewart
On Tue, 11 May 2004 01:40 pm, Tom Foottit wrote:
> The plugin doc is up at:
> http://www.multisync.org/developer/plugin_howto.html
>
> It looks pretty good. I need to review a few of the details (memory
> management, etc.) and give it some more review before giving it to a wider
> audience. This should be a very useful document, so thanks for getting it
> going.
>
> To answer your question about whether the plugin has to know the state of
> each object on the device: yes. The reason for this is that sync APIs vary
> between devices - some have an API that tells you about all
> adds/deletes/modifies every time you ask. Other APIs work via timestamp
> and can tell you about modified and added, but not deleted. Still others
> don't tell you anything and then plugin has to keep track of all states
> (the Opie plugin does this with MD5 sums for example).
>
> I have looked at the KDE PIM plugin code and it looks like a good start
> for addressbook. I set up autoconf/automake for it so makefiles are
> generated and don't have to be hand-editied. However, I need KDE 3.2
> (running 3.1.X right now) to build it, so my compile fails. I'll get y KDE
> upgraded tonight and then once I can build I'll check things in tomrrow.
>
> Thanks again for getting involved - we're happy to have the help :)
>
> Tom
--
Stewart Heitmann <[EMAIL PROTECTED]>
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Multisync-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/multisync-devel
