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

[Jeroen van Meeuwen (Kolab Systems)]

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.

>>    - 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.

>>> 	(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.

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