Storing complex data as folder annotations

Gunnar Wrobel wrobel at
Wed Jun 9 18:39:59 CEST 2010

Quoting Bernhard Reiter <bernhard at>:

> Hi Alain, Hi Gunnar,
> thanks for starting the discussion (again) and making proposals.
> Somehow I consider this a hard problem, which makes it a pain point for me.
> I wonder how we could go forward here. I guess it would require a  
> meeting over
> one or two days to get this really sorted out and some hard thinking.
> Am Montag, 12. April 2010 18:13:20 schrieb Gunnar Wrobel:
>> Quoting Alain Abbas <alain.abbas at>:
>> > 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  
> The main arguments against only using annotations still hold:
> * some servers do not have them, why shouldwe exclude those servers?

Neither the patch for Cyrus nor for Dovecot is really huge. So I think  
it is always feasible to modify a server so that it supports  
annotations. This is not the only feature the Kolab server requires  
after all. And I expect that integrating the Kolab server with a new  
IMAP server will always require a reasonable amount of effort. And  
annotations will only be a part of that. So I'd don't think this is a  
major blocker.

> * space limitations on annotations

I admit that I still consider annotations to be meant to contain only  
short strings. And whereever possible we should probably try to limit  
the use of annotations to short strings. In all situations where we  
would like to store more data we could try to impose additional format  
restrictions to keep the string lengths limited. Take activesync for  
an example: We could limit users to a maximum of ten devices. Not  
wonderful but maybe a reasonable compromise.

> I am also concerned with the different types of configuration values
> a) shared by several users

Non-private annotations.

> b) shared by several clients of one user

Private annotations.

> c) local for one client instance of a user.

Private annotations with a format definition that allows for several  
client-specific entries.

> Note that a client can have several accounts configured and users  
> would want a
> good way to backup that configuration data.

It is not ideal in many regards and I'm certainly not perfectly happy  
about using annotations this way.

However I was opposed to this before and changed my mind because I  
didn't see a decent alternative to storing data for a folder that you  
only have read access to. The ACLs for annotations allow for such a  
scenario though.

Do we have anything we know that we really can't solve by using annotations?

>> 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.
> Given that we also need XML because of the storage format, why not use XML?
> It might be a bit more verbose, but it would save one format parser in the
> clients?

Because it is much more verbose and I still believe be we should not  
consider annotations to be a general purpose data dump. But I agree  
that having a single format type also makes sense. Probably it would  
be possible to condense the XML... hm, yeah, probably you are right.



> Bernhard
> --
> Managing Director - Owner:       (Free Software Company)
> Deputy Coordinator Germany: Board member:
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

______ _______________ _

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

____ _________________ _
E-mail : p at                                 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: <>

More information about the format mailing list