Question: Individual annotations vs One large annotation (conceptual riddle for the interested)

[Gunnar Wrobel]

Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> Gunnar Wrobel wrote:
>> Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
>> > On 11.10.2011 10:30, Gunnar Wrobel wrote:
>> >> Quoting "Jeroen van Meeuwen (Kolab Systems)"
>> >>
>> >> <vanmeeuwen at kolabsys.com>:
>> >>> Bernhard Reiter wrote:
>> >>>> You could make one known annotation to contain the list of dynamic
>> >>>> annotations if this is the issue. On the other hand, if a client
>> >>>> wants
>> >>>> to understand the contents of a configuration option, it would know
>> >>>> the
>> >>>> designated annotation for it as well.
>> >>>
>> >>> Putting annotation paths that may or may not be known to a client
>> >>> into
>> >>> another, one, annotation known to all clients is quite the
>> >>> work-around to
>> >>> avoid having just one annotation to store (all of) the actual
>> >>> configuration.
>> >>
>> >> True and I don't think the clients need to have access to the list of
>> >> potential annotations. But that is also the reason for not choosing
>> >> one big annotation: Not all clients will require access to all of
>> >> them
>> >> because the corresponding features will not always be supported.
>> >
>> > Again, all clients will need access to all feature specific
>> > configuration data regardless of whether the client actually understands
>> > one or more of them features - the least it should be able to recognize
>> > is that *a* feature specific item is already configured and it can
>> > *thus* not configure another feature on top of the folder - or it would
>> > endanger the folder of being configured with two mutually exclusive
>> > features on top of one another.
>>
>> You state again that all annotations are dependent on each other and
>> can potentially conflict with each other.
>
> No, I don't state that. I state that in order to be able to safely configure
> feature $a on a folder, a client must be able to guarantee no feature $b
> through $z has already been configured on a folder, any of which *may* be
> mutually exclusive with feature $a.

Why would the client need to guarantee that? Shouldn't the Kolab  
format spec guarantee that?

>
> If feature $b through $z were stored in annotations the client has no
> knowledge of, it is then also unable to provide such detection.
>
>> I disagreed before and still
>> do.
>>
>
> Then again, there's no strong objections against using one annotation;

True, my objection is not a very strong one. But I am leaning towards  
separate annotations and had the impression Bernhard did as well.

> it
> seems we're arguing just for the sake of arguing, and going  
> absolutely nowhere
> while doing so.
>
> I have yet to recognize any objections against using one annotation.

I mentioned before that I do not see any reason why clients such as  
the Z-Push active sync client should fetch any Horde specific  
configuration.

Cheers,

Gunnar

>
> Kind regards,
>
> Jeroen van Meeuwen
>
> --
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +44 144 340 9500
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08