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

[Georg C. F. Greve]

Hi all,

In the context of drafting KEPs #12 [1] and #15 [2] there has been a 
suggestion made by Jeroen which thus far has gone undiscussed and probably was 
missed by some people. I think it warrants more brainspace as it is a basic 
decision as to which direction we want to take not just for KEPs 12 & 15, but 
also later, subsequent KEPs.

The suggestion was to do an additional KEP to define a folder annotation 
'/vendor/kolab/folder-config' which would be a JSON encoded array that different 
KEPs could store different values into. So KEP 12 would store a 'color' value 
in the folder-config array, KEP 15 would store a 'search' value in the folder-
config array, so it would look a bit like this:

 	/vendor/Kolab/folder-config = { 'search':
    							{ 'search_locations': 'blabla',
       								'params': 'blabla',
       								'filter': 'blabla',
       								'fuzzyness': 'blabla',
 								'async': '0'
 								....
     								}
	    						'color': '8A2BE2'
 							}

instead of like this:

	/vendor/kolab/color = 8A2BE2

	/vendor/kolab/search = { 'search_locations': 'blabla',
       							'params': 'blabla',
       							'filter': 'blabla',
       							'fuzzyness': 'blabla',
 							'async': '0'
 							....
     							}


The rationale for Jeroen's proposal as far as I understood it was:

	(a) new annotations need to be defined in the imap server, which is
		considered an 'expensive' step

	(b) more efficiency in storing annotations 
		(things get stored on disk in the end)

	(c) with one read of the annotation, a client gets a lot of information

	(d) because it is stored in JSON, it is still searchable

(Jeroen: please complement. I am trying to do your proposal justice, but it is 
hard when it is not your own proposal, so please feel free to correct any 
mistakes that I may have made in presentation or substance.)

Personally I have thus far been thinking that individual annotations are 
likely a better path, because

	(a) annotations are defined not ad-hoc by admins during installation,
		but just one configuration of many for each Kolab server version,
		so defining them did not seem *that* expensive

	(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

		(Note: This is under the assumption there is no locking mechanism
		in place for folder annotations, so we cannot protect against this
		scenario.)

	(c) clients only need to retrieve the information they are interested in,
		and since the large annotation may just get fairly large with a lot
		of values stored, this may become bandwidth expensive and slower
		over limited connections

But then it is possible that I am trying to preserve the wrong resource in (a) 
and (c) and am overly cautious in (b) and that in fact the "one annotation for 
most things" approach is better.
 
Which is why I'm counting on the collective wisdom on this list to help us 
sort this out and come to an understanding which path we should take, and why.

Your turn.

Best regards,
Georg



[1] KEP #12:Color configuration storage for resources and categories 
			http://wiki.kolab.org/User:Greve/Drafts/KEP:12

[2] KEP #15: Saved searches and sharing searches across all clients 
			http://wiki.kolab.org/User:Greve/Drafts/KEP:15

-- 
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/673e6d07/attachment.sig>