Re: KDE Plugin code

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