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

[Gunnar Wrobel]

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

> On 15.09.2011 14:47, Gunnar Wrobel wrote:
>> Quoting "Jeroen van Meeuwen (Kolab Systems)"
>> <vanmeeuwen at kolabsys.com>:
>>> The *cost* is perceived to be in;
>>>
>>>    - Updating the configuration file deploying an update/upgrade to
>>> Kolab, when said configuration file or its filesystem metadata has
>>> been
>>> changed in any way (touch will do the trick),
>>
>> We currently already ship this as a template in
>> /kolab/etc/kolab/templates/imapd.annotation_definitions.template
>>
>> So at least at the moment we already intend this to be a file the
>> user
>> should be able to modify.
>>
>
> Don't get me started on kolabconf / settings in LDAP / the perl-Kolab
> library and its future, but I'll agree there's always a way to negate a
> problem like this one I pointed out.
>
> I'll thank you now on behalf of everyone else, for making that a
> packager, distributor, support and/or consultancy issue, obviously to be
> implemented in many mysterious ways as is often the case with different
> packages included with native distribution -still a target for which we
> must get rid of all the little exclusive things Kolab requires we do and
> no-one allows.

I think I don't get your point here. What did I exactly do to create  
an issue for all these people and why does this deserve thanks from  
your side?

>
>>>    - Documenting the ability to opt-out of features by removing the
>>> annotation, and documenting opting in, including all combinations of
>>> annotation keys and values, troubleshooting for and resolving issues
>>> with clients that may or may not assume a certain set of annotations
>>> to
>>> (not) be available,
>>
>> As Georg pointed out: Seems to be easier to do that when having
>> multiple annotations.
>>
>
> Perhaps you misread my comment or what I replied to, as I was pointing
> out that with multiple annotations, the ability to opt-out and
> opt-back-in to any of those is a documentation nightmare (and supporting
> it is bad, too), because 'folder-type' could still be set to 'search',
> but the /vendor/kolab/search annotation may have been removed. Etcetera,
> etcetera, etcetera.

Yes, I misunderstood your earlier comment. I agree that it is  
suboptimal to have several folder annotations per use-case. I admit I  
did not have the time to go through the "search" KEP yet.

In any case I would hope this is not the common case so I don't see  
this as a direct argument against having one annotation per  
use-case/KEP rather than the generic folder config.

>
>>>> 	(b) there is no danger of write-conflicts, e.g. one client storing
>>>> 'color'
>>>> 		while another client is storing 'search' is a scenario where at
>>>> 		least in theory it is possible to lose an unrelated edit of a
>>>> 		different property based on the timing of the two writes, which
>>>> seems
>>>>  		worse than two clients editing the same property, and the last
>>>>  		write winning, which is what would happen if we have one
>>>> annotation
>>>>  		per property/use-case
>>>>
>>>
>>> For the overwriting part, it is a relatively simple clause to, on a
>>> single annotation, preserve the existing contents;
>>>
>>>    $json = get_annotation('folder-config')
>>>    // Check for potential conflicts
>>>    $json[key] = value
>>>    set_annotation($json)
>>
>> This will be easier and cost less if the annotation values are
>> smaller.
>>
>
> The size of the annotation has nothing to do with an applications
> ability to iterate over keys in a JSON object, unless there are going to
> be thousands of keys.
>
> The size of multiple annotations will kill an application needing to do
> a GETMETADATA for all annotations that it understands, still requiring
> the same iteration over cumulatively nearly the same size, but
> cross-referencing between annotation values in order to detect any
> potential conflicts (because the one client may not have understood it
> should not set annotation A because annotation B was already set but
> couldn't be detected because the client is not compatible with
> annotation B).
>
>>>
>>> With multiple annotations however, such would look like:
>>
>> I would expect the clients only write a single annotation at a time.
>>
>
> Have you read METADATA?
>
>>> That said, however, all annotations need to be retrieved regardless,
>>> for both private and shared.
>>
>> I don't see why. If the folder color does not matter for the current
>> view context why should the current value be retrieved?
>>
>
> You've got me. With the one example of the one annotation (currently
> defined) that has no further consequences out of context, obviously
> there is no need whatsoever to ever consider any conflict between any
> annotation or annotation values that are being defined now or will be
> defined in the future. Right...
>
> Whenever the client needs to be determine what objects are (may be) in
> a folder and what the client's behaviour should be like when presenting
> said content to the user in some or the other sensible fashion, the
> client will need to obtain all annotations for both private and shared
> in order to determine precedence between private and shared as well as
> precedence between settings in annotation A vs. settings in annotation B
> -which may be perceived as non-existing conflicts today but will
> ultimately happen even with something as simple as a value format
> upgrade, or an annotation having been updated by a client completely
> unaware of annotation B.

This would mean that we have several annotations per use-case. Or some  
other strong linkage between them. I would like to avoid that as  
stated above. I agree with you that for any given set of linked  
annotations I'd rather prefer a single annotation over several ones.

So in fact I'd be convinced the folder config you suggest is the right  
way to go if I would see that basically *all* folder configurations we  
will create are going to have strong links between them. Maybe I have  
been looking at examples which are too extreme - in the other mail I  
mentioned "horde config" and "zpush active sync config" which do not  
seem to have anything in common and should be maintained separately.

So our positions do not seem to be too far away but so far I fail to  
see the reason for this "overall" linkage between annotations.

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
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de