On Tue, 2004-05-11 at 12:45, Stewart Heitmann wrote: > 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.
Thats right. You would have to write a logic which determins the state of each item yourself. How hard this is depends on what your device returns. > > 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). That would not work with some plugins (eg the Palm Plugin). When i query the palm it returns only those entries that were modified since the last time. So if i wanted to return a copy of _all_ data, i would either have to make a slow sync or keep a local copy of the data, which would be error prone and just plain stupid. And you would have to transfer a lot of data, even when just one contact was modified (my bosses pocketpc has ~ 3000 contacts in it) > > 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 ------------------------------------------------------- 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
