Question: Individual annotations vs One large annotation (conceptual riddle for the interested)

Georg C. F. Greve greve at
Tue Oct 11 13:48:27 CEST 2011

On Tuesday 11 October 2011 13.21:31 Gunnar Wrobel wrote:
> I'm not a fan of abolishing annotations completely either. But I would
> like to be able to make them optional for some of the central
> annotations (such as the "folder-type"). With the current Kolab format
> specification users are unable to move their Kolab data to any IMAP
> provider they choose.

The big question here is: Why would they want to move that data to braindead 
storage? What is the use case?

Because right now there is no use case here that I can see, and making 
invasive changes for all clients and limiting the overall solution through 
addressing a non-existing use case seems pointless.

> Even if the use of annotations/metadata will get
> more common in the future I doubt that providers such as Google mail
> will ever adopt them.

So you don't think they'll implement the RFCs they have been driving?

But even so: If someone wanted to move their Kolab data to Google, why would 
they want to do so by abusing Google as braindead IMAP store instead of its 
calendar and address book functionality? The data is there and can be mined in 
any case, but without the convenience for the user.

If someone wants to use Google, I suspect they'll just use Google, and not 
"crippled Kolab stored in Google."

> I thought Jeroen disagreed with Bernhard on using KEP#9 for allowing
> to store stuff we currently have in annotations in XML objects. But
> that was probably not the main issue but rather the question of
> abolishing annotations completely. The latter is something I also
> don't want as I consider them useful in many situations.

They are the best storage mechanism for some cases.

In other cases XML is better.

It's about choosing the right tool for the job, because between these two 
tools, Kolab can achieve its full potential.

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at
t: +41 78 904 43 33

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list