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