On Tue, 11 May 2004, Stewart Heitmann wrote: > On Tue, 11 May 2004 09:02 pm, Armin Bauer wrote: > > > 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) > > Hmm, thats interesting. > I hadnt anticipated any devices would behave like that.
Actually, any device with a "good" sync API is like that. The Evolution API (while far from perfect) works this way too for example. The goal for the Opie syncing API is to get to this state as well. > So (out of interest) what would happen if you decided to sync your Palm on two > different desktop computers? Would each computer get a different set of > changes? Not sure about Palm, but Evolution (for example) uses an identifier assigned by each user if the API. So when someone with identifer X asks for changes the first time they get them all, and then each subsequent time identifier X only gets the changes since last time. > And yes downloading everything is excessive, but ONLY if your device is > one of the "smart" ones capable of reporting on DELETED items. > If your device cannot report on DELETED items then you MUST download > everything (UIDs at least) anyway just so you can tell what items (if any) > are now missing from the device. Correct? Yes, this is correct. > So it seems "smart" and "dumb" devices have very different requirements. > So allow me to alter my original suggestion somewhat to try and > accomodate both camps: > Instead of REPLACING the get_changes function, what if my suggested > "get_everything" function be seen as an ALTERNATIVE to the get_changes > function. So when the sync-engine loads the plugin, it looks for either > "get_changes" or "get_everything" and calls the appropriate one. That would only solve the problem for your particular class of device (the KDE PIM API) by figuring out which ones are deleted. There are even "dumber" APIs (like the current Opie one) where you also have to figure out what if anything changed with each entry. For this to work the sync engine would need to be in the business of keeping details on each entry, figuring out if it changed, etc. I don't think we want to get in to putting all of that in the sync engine. > I am concious of introducing feature bloat to the sync-engine at this point. > Nevertheless, I still think the benefits to the developers of plugins for > "dumb" devices could make this extra functionality worthwhile. My feeling is that there aren't enough devices in this specific category of "dumb" to make it worthwhile :) I've been trying to evangelize smarter sync APIs. The Opie roadmap calls for this now, and the Mozilla calendar people we have been talking to want to work the same way. IrMC and SyncML (commonly used on mobile phones) also work in a "smart" manner. 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
