Re: [Opensync-users] 1 <-> n matching was: Debian Packages 'incomplete'

[Robert S. <Rob...@ba...>]

> > -how can I influence the format conversions a sync group uses?
> 
> which format do you mean exactly? It basically works like this:
> 
> - A device sends a change object in the format that the device supports.
> - The change is then converted to the internal xml format to be able to
> compare it to other change objects

That's not the way to go. Like a device with its format is a "plugin" in
opensync, the comparing should be done by a module/plugin, too!! If I
wish to sync a directory to my mp3-player, I probably want a binary
comparision, shortend by "it's fine if size, time stamp and name are the
same". - I defintely don't want the files to be converted to some
internal whatever, because I want exact copies.

Syncing contacts I'm probably fine with converting them to different
formats. Automatically, but maybe filterd, too. - E.g. changing phone
numbers to/from international format so that the matching at a later
state succeeds.

> - If a conflict happens, the change is converted to a format specified
> by the GUI, so that it can display the conflict to the user

The GUI should be able to order an object in whatever format, on behalf
of the user. E.g. "Problem: opensync helpless on object A" --> user
says: "okay, present me that as vcard..., oh no, present that as binary,
ah, lets tries to see it as "simple number <-> name format". - Okay,
make matching with "xyz-matching" module and look for "Richard" --> one
data set named "Richard" found --> JOIN..."

Maybe the GUI can work like an extra device in a sync group. It should
have the most complete data structures compared to it's other members
and should be synced to first, dictating resolutions to the other
members.

> > -how can I dictate what data records of one member matches at an other?
> 
> since all formats are converted internally to the xml format, you just
> have to map the fields of one item to the fields of the xml format. At
> the moment the internal format is not yet documented since we have to
> change this format to allow merging of changes.

This should be modular. And stackable.

A match-module has at least two "sides" and a matching data base. It
gets on one side new objects in a format the module likes, or it gets
conflicting ones together with the last matching. It can now search on
the other side for matching objects break the old or make new relations.
It has the posibility to relate not 100% identical objects, provoking
updates to one or both side with the related object.

On similar devices (with the same native format) it would be nice to
stack a binary match module on top...

> > -can I add an stack of matching-modules to a sync group?
> >  E.g. I need an multi-to-one matching. A dumb mobile with number <-->
> >  name only and an computer with one contact --> a bunch of numbers.
> >  I think about an module which hides these multi-matchings and shows to
> >  each side only alike records and does the _merging_ and _splitting_.
> 
> uh... thats _really_ complicated. opensync works on an object level and
> has to establish uid mapping between these objects. so opensync itself
> can definitely not handle this itself. you could, of course, split a
> contact with several phone numbers into items with one phone number.
> 
> But:
> 
> - you have to keep the mapping of your contact IDs to the opensync uids
> somewhere
> - every time one of the split contacts gets changed, you need to read in
> all other split contacts that belong to this uids to assemble the final
> contact that is send to opensync
> - you have to decide which fields are universal to all split contacts
> (name probably) and which are unique (telephone probably)
> - what happens if you can the value of a universal field? should the
> other side be updated then? what about the field in the other split
> contacts?

I think about universal "join/split" modules. Okay, splitting is
information loss, so, easy. Joining would be more powerfull with the
help of sync group members with richer contact sets. - When the number
123 and 456 is already on the other side, the name is probably not so
important. If I cant find "Richard work", but a "Richard", the number
probably belongs to him...


Bye,
	Robert