[Kolab-devel] [NEW KEP] KEP #9: Storage of configuration information, new folder- and object type

[Jeroen van Meeuwen (Kolab Systems)]

Georg C. F. Greve wrote:
> Dear all,
> 
> Based on the conversations we had about how and where to store which kind
> of configuration information the following KEP has been started based upon
> the ideas that Bernhard outlined in his emails [1,2] and is now awaiting
> your review and consideration:
> 
> 	http://wiki.kolab.org/User:Greve/Drafts/KEP:9
> 
> All followup discussions should go to kolab-format at kolab.org.
> 

I think this is partly the right, partly the wrong route.

A folder, say my INBOX/Calendar, requires a /vendor/kolab/folder-config 
value.priv 'color'. That is to say;

- please allow the use of 'value.priv' where appropriate,
- please consider storing some configuration in /vendor/kolab/folder-config

My color is mine and mine alone - in the interest of full disclosure, I like 
different shades of pink - and sharing it with you should not put the color of 
my choice on your screen.

You may thus want to annotate the folder with your own folder-config 
'value.priv' 'color'.

In other cases, where the configuration is more 'global', such as a list of 
identities eligible for use with the IMAP account, such as 'Lucy Meier on 
behalf of Georg Greve <georg.greve at kolabsys.com>', etc., as well as perhaps 
application specific local subscription lists, would typically be more 
appropriately stored in an XML object of type 'configuration' in a folder 
marked as containing configuration type objects (/vendor/kolab/folder-type 
configuration). In the latter case, it seems to me the KEP applies most of the 
necessary rules.

For consistency in terms of terminology, may I recommend not referring to "all 
non-email folders" ('cause all folders of any type do contain email) but 
instead use the phrase "folders not of folder-type email".

Additionally, I would like to point out the INBOX folder MAY NEVER be of type 
'configuration'.

Furthermore, we may require the need for dictionary hashes in the 
/vendor/kolab/folder-config. The example concerns folder-type event most 
prominently;

- color,
- identity (for new events, replies to events),
- enable/disable/only-attending alarms,
- ...

It seems reasonable to choose a type of hash, if any such is available that 
can be parsed by all if not most clients, a routine to fold and unfold / 
serialize and unserialize / ..., and to always store as a hash right from the 
beginning. Note that the METADATA RFC [1] specifies no maximum length, though 
I'm sure there is one.

While we're on the subject, I would like the KEP to allow for / refer to the 
future implementation of RFC 5257, IMAP - ANNOTATE Extension [2]. This 
eliminates our need to store custom flags for sharing them across application 
(i.e. \work, \private, \blah, \roundcube-reminder-sent) in an additional 
configuration XML, as maybe other configuration items would be more suitable 
for implementation through RFC 5257.

Kind regards,

Jeroen van Meeuwen

[1] http://tools.ietf.org/search/rfc5464
[2] http://tools.ietf.org/search/rfc5257

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