8:50 p.m.
On Sun, Jan 09, 2011 at 07:30:11PM +0100, Lukas Zeller wrote:
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.
It's trivial surely (I just thought about this a little) you have a
'dictionary' type format for the data, each file/record simply contains
fields which consist of a type (i.e. a field name) and the data for that
type. Thus every device that uses the data can extract any or all of
the data as it needs. If some device decides to add a new field then it
does so, that new data gets passed around with all the rest and if other
devices need it or display it they can but if they don't need it they
just ignore it.
The only downside is wasted space on devices that don't use all the data
but in this day and age of cheap memory even 'phones have a silly amount
of memory so I don't see this as an issue at all.
> 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.
I'm 64, been programming since the 1970s! :-)
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.
Yes, absolutely agree and if you make the format inherently flexible and
able to add any of these fields without breaking existing devices that's
what we need isn't it? The continuous chase to keep up with changing
data is almost bound to fail.
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.
The more I think about it the more I believe that a format which doesn't
define the fields but does define how to represent fields of any type
seems to me to be the right way to go.
I *fear* that XML is the obvious candidate, I just don't like it
personally. :-)
--
Chris Green