On Mon, 2005-01-03 at 15:42, Hubert Figuiere wrote: > Armin Bauer wrote: > > > > Yes a internal standard should be defined, so that we can sync vcard3.0 > > <-> intenal format <-> vcard2.1 > > Why not using the VCard 3.0 data model and use that to convert from/to > anything else, including Palm.
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 - it is hard to parse. There are no good free parsers for the vcard standard - it is not flexible my vote therefore goes to a xml based standard that will be used in opensync unless someone convinces me of something better of course :) 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. > > I'd use some kind of vector containing key/values pairs to specify a > record. We can use the same for calendar and implement iCalendar 2.0 > data model on top of that. > This IMHO should be the kind of data OpenSync use all along, leaving the > plugins the choice of the final format. > > > 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
