Question: Individual annotations vs One large annotation (conceptual riddle for the interested)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Thu Sep 15 18:43:01 CEST 2011
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
>> changed in any way (touch will do the trick),
> We currently already ship this as a template in
> So at least at the moment we already intend this to be a file the
> 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
>> - 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
>> (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,
>>> (b) there is no danger of write-conflicts, e.g. one client storing
>>> 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
>>> worse than two clients editing the same property, and the last
>>> write winning, which is what would happen if we have one
>>> 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
> This will be easier and cost less if the annotation values are
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
>> 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.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
More information about the format