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.
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?
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?
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 way plugin developers can choose to implement the particular version
of the callback that best suits their device.
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.
Stewart
-------------------------------------------------------
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
