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

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at
Sun Oct 2 18:55:24 CEST 2011

Bernhard Reiter wrote:
> Hi Georg,
> On Wednesday 28 September 2011 18:23:32 Georg C. F. Greve wrote:
> > That said: It would have been helpful to get your input on the actual
> > question discussed in this thread.
> under the assumption that annotations must be kept and configuration
> must be stored in there, I would prefer individual annotations and not one
> large one.
> I could read out some possible technical advantages for using one large
> one, but to me they are not the deciding factor. Many problems will have
> to be solved for one annotation and this also means they can be solved for
> many annotations as well.

I've already stated for individual annotations all clients require the list of 
full paths of the annotations in order to be able to determine whether or not 
there could be any problem. The problem stated does *not* exist with using one 
annotation, and does exist with multiple annotations - to argue the same 
problems need to be resolved in each proposed solution is therefor false.

> And in this case it just seems conceptually 
> cleaner to separate data groups from each other that are separate already.
> I can image there are some that are so closely related that it would be
> okay to put them in one annotation, but not all of them.
> Best Regards,
> Bernhard
> ps.: Just asking myself two questions again: Is there a notification system
> for changed annotations in the IMAP protocol and implemented in Cyrus IMAPD
> and Dovecot? Is annotation length still limited and does not count towards
> the quota?

Yes, there is a notification system, annotation size is not limited, and it 
does count towards the quota.

Kind regards,

Jeroen van Meeuwen

Senior Engineer, Kolab Systems AG

e: vanmeeuwen at
t: +44 144 340 9500
m: +44 74 2516 3817

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the format mailing list