Storing complex data as folder annotations

[Gunnar Wrobel]

Hi Alain,

Quoting Alain Abbas <alain.abbas at libertech.fr>:

> hi Gunnar
> well but for the folders where the user doesn t have write rights (this
> is my case with zpush ) ?

indeed I did not consider the ACL problem. This completely invalidates  
my suggestion. The fact that it is necessary to allow users to store  
configuration data on folders that they have no other right than  
"lookup" does however mean that there is really no other choice than  
using the annotation system. Any other IMAP based solution that comes  
to my mind and that would allow this seems even more broken than using  
IMAP METADATA to me.

So that would leave complex data in the annotations. However I would  
not like to use PHP serialization there. I think JSON would be more  
appropriate as it is not bound to a specific language.

Cheers,

Gunnar

> and how to hide it for the user
> (the user always make bad things :-)
>
> Alain
>
> Gunnar Wrobel a écrit :
>> Hi,
>>
>> as a follow up on the recent IMAP folder annotations discussions in
>> kolab-devel@ I'd like to propose extending the format so that we avoid
>> misusing the IMAP METADATA RFC. I did not invest much time into this
>> proposal and I see it as a rough idea for starting the discussions.
>>
>> I'd like to add a new Kolab format definition named "metadata". This
>> would be the xml format:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <metadata version="1.0">
>>   <!-- Common fields -->
>>   <uid>(string, no default)</uid>
>>   <creation-date>(datetime, no default)</creation-date>
>>   <last-modification-date>(datetime, no default)</last-modification-date>
>>   <product-id>(string, default empty)</product-id>
>>
>>   <!-- Metadata specific fields -->
>>   {<element>
>>     <name>(string)</name>
>>     <value>(complex)</value>
>>     <client>(string, default empty)</client>
>>   </element>}
>> </metadata>
>>
>> The "<value>" node could contain arbitrary complex XML. Clients would
>> be free to store their specific data in this node. Any new value
>> should however be documented in the Kolab wiki. If several clients
>> need to store/access the same configuration value they are free to do
>> so and they may ignore the "client" node (it must not be rewritten
>> however). Any configurations of general use might be included into the
>> Kolab format at some point and get "official" this way.
>>
>> On IMAP servers that do not support the METADATA extension the
>> "metadata" object can be used to store ALL annotations on a folder.
>>
>> The mail with the "metadata" XML attachment always has the ID "METADATA".
>>
>> Cheers,
>>
>> Gunnar
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Kolab-format mailing list
>> Kolab-format at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-format
>>
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/format/attachments/20100412/272c7720/attachment.sig>