<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello All <br>
Another point about the storage <br>
Why Xml and why not Json ? <br>
Json is now native in all the languages and less cost about
parsing;generation and the size that iit is <br>
great regarding the IMAP annotation Storage. <br>
ps: Z-push/BAckend stores the info in Json Format. <br>
<br>
Alain <br>
<br>
<br>
<br>
Jeroen van Meeuwen (Kolab Systems) a écrit :
<blockquote cite="mid:201107052348.03951.vanmeeuwen@kolabsys.com"
 type="cite">
  <pre wrap="">Georg C. F. Greve wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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:

        <a class="moz-txt-link-freetext" href="http://wiki.kolab.org/User:Greve/Drafts/KEP:9">http://wiki.kolab.org/User:Greve/Drafts/KEP:9</a>

All followup discussions should go to <a class="moz-txt-link-abbreviated" href="mailto:kolab-format@kolab.org">kolab-format@kolab.org</a>.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
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 <a class="moz-txt-link-rfc2396E" href="mailto:georg.greve@kolabsys.com"><georg.greve@kolabsys.com></a>', 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] <a class="moz-txt-link-freetext" href="http://tools.ietf.org/search/rfc5464">http://tools.ietf.org/search/rfc5464</a>
[2] <a class="moz-txt-link-freetext" href="http://tools.ietf.org/search/rfc5257">http://tools.ietf.org/search/rfc5257</a>

  </pre>
</blockquote>
<br>
</body>
</html>