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

Gunnar Wrobel wrobel at horde.org
Tue Oct 11 11:35:31 CEST 2011


Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> 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'
> right.
>
> 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.

The sub-folder approach is certainly not the best approach. But what  
would be the problem of storing private annotations in your own  
configuration folder?

Cheers,

Gunnar

>
> Kind regards,
>
> Jeroen van Meeuwen
>
> --
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +44 144 340 9500
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08





More information about the format mailing list