Where to store different configurations (Re: Storing complex data as folder annotations)

Bernhard Reiter bernhard at intevation.de
Fri Aug 27 16:01:55 CEST 2010


Am Mittwoch, 9. Juni 2010 18:39:59 schrieb Gunnar Wrobel:
> > 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.

If you are able to modify the server...
Under many circumstances, people will just have an IMAP server
which is not under their control and they still would be able to use many 
function from the Kolab Concept.

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

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

This is really ugly, but I think you are aware of that. :)

> > 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?

* Usage of many Kolab features on general IMAP servers.
* Saving more configuration data (solvable, but getting really ugly).

Currenlty I am thinking that we should propose a configuration object
within an email and of course in a folder that is purely for configuration
objects.

This has two major parts that need to be specified:
I. Hierarchy of configuration information.
   I.a) Over different accounts (aka storage locations)
   E.g. my IMAP account on a Kolab Server also could contain configuration 
        for my Kolab Client for folders within my local storage or 
        IMAP account at the FSFE. 
   I.b) between folder. Folder form a tree. 
        Suggestion: if you get more to the leaves, the configuration
        takes precendence for that branch.
   I.c) Within one folder (or one object)
    
II. How to specify the configuration within the object.
    At least there will be two kind of configurations:
    II.a) General, this means several types of clients
          will honor them. Maybe really specified.
    II.b) More client specific configuration information, so basically
          a client can put in anything there it wants.
          This is important to not force clients to much.

We solve the read-only folder problem by just saving the configuration
for that folder to one of my writable configuration folders.
I suggest that each account gets a special configuration.default folder
right below INBOX and the idea is that configuration folders will not be shown
in the email view (by default), just like other groupware folders.

For folders that are going to be shared between several people (and possibly 
clients), it can get convention to have one configuration subfolder
at the root of the folder tree that is going to be shared by the same people.
It just need to be created once there is the need for commonly shared 
configuration settings. E.g. Kontact could save some templates or signatures
in there for a sales at demo.kolab.org functional email address.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20100827/ce65d5ef/attachment.sig>


More information about the format mailing list