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

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at
Wed Oct 5 12:57:45 CEST 2011

Bernhard Reiter wrote:
> Am Sunday, 2. October 2011 19:01:10 schrieb Jeroen van Meeuwen (Kolab
> Systems):
> > > Do not use annotations for saving configuration.
> > > Use configuration Kolab IMAP objects [1] from KEP#9.
> > 
> > XML objects of type configuration do not allow for personal configuration
> > to be stored in / attached to a folder. They only allow shared
> > configuration.
> True, this is a drawback of the object configuration method,
> as I have already answered Alec.
> I think it can be worked around in a reasonable way, though:
> If it is a folder tree I have admin rights, I could create a subfolder
> for myself to attach my personal configuration to the folder.
> For other uses I can just use a different configuration folder
> which is personal to save additional configuration for this folder.
> As there will be several places for configuration with most applications
> anyway, I think this can be handled fine.

Creating a sub-folder of a folder for the sole purpose of storing one personal 
configuration item with configuration for the parent folder is definitely not 
the most sustainable approach, as the number of folders would quickly become 
x*(y+u) + 1, where x is a number of folders, y is the total number of users 
with admin privileges, and u is the number of other users configuration needs 
to be stored for - plus the original folder.

Also, it's particularly difficult for a client to know what the canonical 
username for a target user is, in an attempt to create said folder.

Also, the restriction to 'admins' only creates the restriction to only 'admin' 
users being able to save configuration. For shared/ folders, this doesn't fly 
as non-admin users will have to save configuration too.

Also, the 'admin' right doesn't imply the right to create a (sub-)folder. One 
needs the 'c' right for this, and though the 'a' right implies one can assign 
him/herself the 'c' right (temporarily?), the 'a' right does not imply the 'c' 

Also, inherentance of configuration rules and application would be messed up 
with client folders giving the directions for parent folders, which will 
become very hard to parse as child folders are to be inheriting from parents, 
not vice-versa.

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