Re: [Opensync-devel] Questions about capabilities

[Henrik /K. <he...@ka...>]

Daniel Gollub wrote:
> 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 ...
>   
ACK. Maybe one day I will provide a patch...
>
>   
>> 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 
> ...
>   
Looking forward to that!
>> 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..
>   
Right, but I do not think this DisplayName should come from the caps, it 
should come from the format...
>> 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 ...
>   
I could not find MaxOccurs (or MinOccurs) in SyncML.
> Maybe if minoccurs can not be met - maybe the demerger should demerge the 
> entire cap?
>   
Possibly....
>> 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.
>
>   
I still think the datatype should be defined by the format.
How can you have a format that says it wants parameter x as an integer, 
and a capability that says it can only handle x as a string?
If you want digits, no characters, and similar stuff, a regex would be 
better, I think.
>> 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  ...)
>   
ACK
As far as I recall, SyncML just has "Size", ie. our "Max".
>> 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.
>
>   
This has nothing to do with min-max. This looks like a regex to me...
>> 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 ...
>
>   
ACK
>> 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.
>   
OK, let's continue this on a separate thread...
>
> 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 ;)
>   
I will try to contribute whenever and whereever I can - preferably 
without specialization!

/Henrik