On Mon, 2005-01-03 at 18:25, Hubert Figuiere wrote:
> Armin Bauer wrote:
>
> >>Why not using the VCard 3.0 data model and use that to convert from/to
> >>anything else, including Palm.
> >
> >
> I was not clear enough
> > 3 reasons:
> >
> > - the vcard standard does not support all available fields from other
> > formats (for example custom fields of a palm). The standard we choose
> > HAS to support everything
>
> we can add extensions in our data model to handle what we want. It is
> just an array of key/value pairs.
>
> > - it is hard to parse. There are no good free parsers for the vcard
> > standard
>
> I talked about data model, not file format :-) A bunch of struct in
> memory WITH object persistence for storage.
> A record contain fields (named by a string) and each field can have
> attributes (key/values, the same way). Then we synchronize the records
> comparing the fields.
>
> We would use it like this
>
> OSRecord my_record;
>
> // add a bunch of fields
> my_record.addField("name", "foo");
> my_record.addField("phone", "+1 555 555 5555");
> // set attributes for phone field
> my_record["phone"].addField("type", "home");
> // add a field with a unique UID
> my_record.addField("uid", genUID());
> // tell this field is the UID of the record
> my_record.setUidField("uid");
ok. i really didnt get you correctly.
Something like this was exactly what i had planned.
I thought you talked about using vcard as the underlying format to store
this :)
So we would use xml as the underlying format and provide a api to
manipulate these xml docs. Then we need to define the converters from
each format to our format ("N" from vcard has to be split and stored in
the fields "FirstName", "SurName" etc)
>
>
> > - it is not flexible
>
> Ours would be. See above
>
> >
> > my vote therefore goes to a xml based standard that will be used in
> > opensync unless someone convinces me of something better of course :)
>
> xml could be for storage and/or persistance. This does not define any
> data model but just a data format.
> You would do something like
>
> my_record.loadFromXML(xml_string);
> my_record.saveToXML(xml_string);
>
> >
> > And it should also be possible to implement some sort of "merge" algo
> > for the format we choose. Although we dont need this in the beginning,
> > we definetly need the later.
>
> We can have a generic merge algorithm for the above records. This still
> require that we have a local copy on disk to handle case where the same
> record is modified on both sides. It would also allow n-way sync merge
> (sync evo + palm + phone in one round).
>
>
> Hub
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Multisync-users mailing list
Multisync-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/multisync-users
