Menu
▾
▴
Re: [Opensync-devel] Questions about capabilities
|
From: Daniel G. <go...@b1...> - 2009-10-24 13:00:22
|
On Friday 23 October 2009 11:32:46 am he...@ka... wrote: > 1) > In capabilities.xsd we have an element called Parameter with > maxOccurs="unbounded". > In opensync_capability.h/c we have osync_capability_set_parameter whichs > sets ONE parameter. > As far as I can see, it sould be possible to have several parameters (such > as both Location and Pref for an Address). > So: is this a bug in the capabilities API (i.e. opensync_capability.h/c)? Yes, that's a bug - we need to break the API for this ... > > 2) > A well-formed XML document must have exactlny one root node. > According to capabilities.xsd the root node must be <Caps> which has an > attribute called CapsFormat. > If a plugin is offering capabilities in different CapsFormats (e.g. > because it supports both vformat and xmlformat), how would this be > specified? > Suggestion: Rename <ObjType> to <ObjTypeCaps> and move the CapsFormat > attribute from <Caps> to <ObjTypeCaps>. > (API change probably needed as well). This requires some more discussion i guess. Actually the capsformat is independent of the objformat .... i still need to describe how the capsformat thing works. I will go in more details in a separated mail about capsformat ... > > 3) > capabilities.xsd defines that <Cap> can have a <DisplayName> child, and > that <Parameter> can have a <DisplayName> child. > When would we ever want to show an end-user the name of a capability or > parameter? Maybe thats useful to let user now which fields will be not synced and due to missing capabilities support - and will not get lost. The idea of DisplayName comes from SyncML - SyncML spec has this defined. So some phones are providing this information .. so if this is available we might want to use this information on the first Sync or so to inform the users which fields will not appear on member X.. > > 4) > capabilities.xsd defines that <Cap> can have a <MaxOccurs> child, but no > <MinOccurs> child. > Is this a mistake, or is it because the demerger would not be able to > handle it anyway (i.e. what should the merger do if the change does not > include the attribute for which MinOccurs > 0 ? ) We still can add this .. but first there needs to be a real use case in the "wild" ... This capabilities schema is based on the capabilities description from SyncML specs. AFAIK they haven't minoccurs either ... Maybe if minoccurs can not be met - maybe the demerger should demerge the entire cap? > > 5) > capabilities.xsd defines that <Cap> can have a <Type> child, and that > <Parameter> can have a <Type> child. > What is the purpose of this? This is also from SyncML Spec. maybe one day this could be handy for some merger and demerge. The Type is something like chr, string or something like that ... e.g. in SyncML say set for capability N (in case of a vcard, Name) Type to "chr" ... which is character ... and some devices also set max and min ... > I would expect that the type is defined by the format-plugin. Hmm, why? e.g. the vformat is very generic and can handle for example the entire vcard spec ... now imagine that some devices has limited support for the field TEL - e.g. only integers - no characters. But yeah that's just an example i made up ... need to check for a better example which exist in the real world. > > 6) > capabilities.xsd defines that <Cap> can have <Min> and <Max> children. > I would like an example of how this would be used. Max number of characters for example ... For capability Name, only characters - but max are 32 characters. Again, this is from the SyncML capabilities definition (not quite sure if this included also min or if i made this just up ...) > I.e.: Are there any conceivable format elements which have an unrestricted > range, or say a range of A-B, but where a plugin/member would only be able > to handle part of this range? Telephone numbers. Most devices only supported 0123456789 +#*pcw and so ... maybe some more ( ) whitespace ... and some allow dashes - some not. > > 7) > capabilities.xsd defines that <Cap> can have a <MaxOccurs> child. > Do we really expect demergers to handle this? I guess i added this also because it was part of the SyncML capabilities definition. Real life Example: Only one Name field MaxOccurs of Telephone fields 3 And yeah, we might want to handle this in demerge in the future. Imagine you have a contact with 5 telephone numbers, but your mobile supports only up to 3 numbers. The mobile might would reject the entire contact if OpenSync would try to send a contact with 5 numbers ... or even worse, it would tolerate this and loose two telephone Numbers if this entry get synced back, due a change. So with the maxoccurs information we could merge back the 2 not-sync numbers ... But we still need to solve the question which numbers should get synced ... you could just sync the first 3 numbers in a contact. And prefer the numbers which have the type preferred ... > > 8) > The current logic in _osync_obj_engine_mapping_find is: > Clone (i.e. make a complete copy of) change1. Demerge fields from the > clone which are not in caps2. > Clone (i.e. make a complete copy of) change2. Demerge fields from the > clone which are not in caps1. > Compare the two cloned objects. > To me this seems unnecessarily complicated and incurs a performance > penalty. Why is this not implemented as a more "intelligent" compare > function, which takes capabilities into account? [...] This is pretty new code and more or less just a proof of concept. If you came up with a more efficient solution, let me know. This was the last thing i was working on ... it's not completed. Btw. do you want to specialize for the merger/demerger capabilities handling in OpenSync? You already got a pretty good understanding how things tick ... even if they don't tick as expected ;) Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
