[Opensync-devel] Questions about capabilities - again

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

I am not sure if this ever reached the list.
Apologies if you get it twice

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)?

2)
A well-formed XML document must have exactly 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).

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?

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 ? )

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?
I would expect that the type is defined by the format-plugin.

6)
capabilities.xsd defines that <Cap> can have <Min> and <Max> children.
I would like an example of how this would be used.
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?

7)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child.
Do we really expect demergers to handle this?

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?

/Henrik