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

Georg C. F. Greve greve at kolabsys.com
Thu Sep 15 14:05:48 CEST 2011


On Thursday 15 September 2011 11.47:49 Jeroen van Meeuwen wrote:
> The "cost" is not when /etc/imapd.annotations.conf needs to be altered,
> *if* the consumer has not edited said file. The *cost* is implied when
> the consumer has a copy of that file that is modified outside of package
> management - in which case proper packaging methods will not want to
> alter the file's contents.

True, although I guess we will never be at the point where we won't define 
*any* additional annotations, even the folder-config annotation would have to 
be defined. 

So there will always be SOME edits of the annotation file.


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

True.

Although the ability to opt-out or block a certain feature installation wide 
in a reliable way would be an argument for the annotation per use case, 
because an annotation that is not defined is simply not usable, whereas a 
key/value pair for folder-config can be set regardless of whether it is meant 
to be set or not. 


> For the overwriting part, it is a relatively simple clause to, on a
> single annotation, preserve the existing contents;

This is not the case that I was concerned about.

Think of the following:

	Client A reads folder-config

	Client B reads folder-config

	Client A sets 'search' to new value

	Client B sets 'color' to new value

The modification of 'search' by Client A is now lost in a way that would be 
fairly hard for the support department to track and resolve, and the user 
would likely complain about arbitrarily lost settings. 

When asking others whether they changed that value back, they'll rightly say 
that they did not touch the 'search' setting.



>    - For each annotation, the shared as well as the private values

...if the annotation is defined private and shared for this use case.


>    - With one annotation any potential conflict can be detected both
> when merely 'visiting' the folder as well as when attempting to 'alter'
> the folder, whereas with multiple annotations the retrieving of all
> annotations and values and resolving said conflicts is mandatory,

Actually you only need to retrieve the annotations that pertain to whatever it 
is you're planning to do, e.g. a change of color can ignore search.

Only with the large annotations you always must read everything.


>     If a client not compatible with 'search' specifically where to be
> able to detect (potential for) conflict, it;
> 
>       1) would not know to retrieve the '/vendor/kolab/search'
> annotation, but
>          - it would also not know what /vendor/kolab/folder-type
> 'search' was for, and
>          - any potentially pre-populated search data is completely
> wasted on said client.

Yes, although this is equally true for the large annotation, as this is about 
the new folder-type idea in KEP 15, and not the question whether or not to go 
with one annotation per use case or one large annotation.

If a client does not know about KEP 15, the 'search' annotation and the 
'search' value in folder-config are both equally lost on the client, there are 
no obvious advantages or disadvantages to either.

As to the new folder-type, if the client does not know about KEP 15, it also 
does not know that it *MUST NEVER* change objects in a prepopulated folder, so 
it would happily allow the user to do this, enabling diverging datasets, 
inconsistencies, and lost data.

So a client not knowing what to do with that folder and just ignoring it may 
in fact be the better option.


> There is a locking mechanism in place for folder annotations, similar
> to the locking mechanism on IMAP folders, contents and metadata such as
> flags.

How exactly does it work?

I guess we then would need to specify that a client would always have to do

	#1: Lock
	#2: Re-Read
	#3: Modify
	#4: Write
	#5: Unlock

to safely modify a folder-config annotation. The additional read is a bit of 
network overhead & delay, but probably not prohibitive in most scenarios.


> How large an annotation is exactly depends on a variety of factors
> including but not limited to the complexity and brevity of a query
> language for search, which is yet to be explored / defined.

It depends on that and on what else will then go into this annotation in the 
future provided we define this as the canonical way. So I see potential for 
this annotation to grow beyond 10k easily.


> That said, however, all annotations need to be retrieved regardless,
> for both private and shared.

True. 

But only those you actually need at the time, not all of them all the time.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110915/d760321e/attachment.sig>


More information about the format mailing list