On Jan 9, 2011, at 18:17 , Chris G wrote: >> Sync peers all have slightly differening ideas of the concept "calendar >> item" or "contact", so the real challenge is not just to find which side has >> most recent data, but especially which data is available at one side at all. >> If you just choose "most recent", you'll eventually loose all data but what >> the dumbest (most limited) sync participant can store. >> >> Just imagine a mobile which stores name and tel numbers, but no postal >> address. If the most recent update (say, to a telephone number) comes from >> such a device, there's a whole lot of field by field merging magic needed to >> avoid loosing the postal address a more capable device might have. > > I'm designing (in my mind) the way the data is stored as well as the > synchronisation system. > > If the data is stored as one file per record - e.g. each address/contacts > entry is a separate file then I see no major issue. *Both* ends store > all the data, name, address, phone number, E-Mail and whatever. Then > an rsync type approach of always keeping the latest one will work pretty > well - the only case it won't handle is if both ends are changed between > synchronisation runs.
I see. However this is more a file based approach to database replication than to PDA sync. You postulate that all peers need to understand one common format for each data type. This is something that I've never seen happen in reality. Not even plain text is always exchangeable without conversions (line ends, character set), yet alone more complex structured data. So while it is certainly desirable to reduce the conversion needs as much as possible by using data exchange formats that are as universally usable as possible, a sync architecture IMHO always needs to deal with conversion. > By the way, no, I can't imagine a mobile which stores only names and > telephone numbers! :-) You're probably too young, then :-) These things have existed and I have some lying around here. Seriously, you're probably right regarding what we today consider PDA data, i.e. contacts and calendar entries. We can more or less assume that modern back-ends for PDA data are able to store everything for contacts and calendars (oops, Outlook IMHO still has a fixed number of fields for telephone numbers...). > Part of the point of synchronising two devices > (for me anyway) is to have the same data on both, by which I mean *all* > of the same data for a given person. And that *all* will continue to expand. Today it's tel+email+postal+im. But what's with the most recent blog entry, geo coordinate, twitter status, hires photo, github commit? And the relation between all this? Even simple meeting invitations is something today's backend often have a hard time to get right. All of this will eventually become (if it hasn't already) part of what we today call a "contact". But capabilities will be added to some systems sooner than to others. With the result that we'll have quite similar situations as my (admittedly a bit outdated) device-with-no-postal-address scenario, just on the next level. I see no chance for a sync solutions that relies on *the* format that can represent everything. Lukas Lukas Zeller, plan44.ch [email protected] - www.plan44.ch _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
