Where to store different configurations (Re: Storing complex data as folder annotations)
wrobel at kolabsys.com
Mon Sep 20 11:04:30 CEST 2010
Zitat von Bernhard Reiter <bernhard at intevation.de>:
> 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
> 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
> * 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
This is getting weird. Now that I'm in favor of annotations you start
being in favor of configuration folders/mails :)
> 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.
Ah, I didn't see that when I wrote my last response. Yes, this makes
sense to me so I'm back to configuration folder/mails, too.
> 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.
Without having invested too much thought into the different problems
one might get with this approach, I think that your suggestions make
sense and we should go into that direction.
I can imagine there will be some hairy cases when it comes to the
hierarchy of the configuration information. And I wonder how
annotations will fit into that.
I assume at least that we are not about to drop annotations
immediately (if ever). I still believe that they are quite nice for
setting things like the folder type. But of course it is great if they
are not mandatory anymore.
So how are we going to start the specification process?
> 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
Developer, Kolab Systems AG
e: wrobel at kolabsys.com
t: +49 700 6245 0000
pgp: 9703 43BE
This message was sent using IMP, the Internet Messaging Program.
More information about the format