Declaring a new folder type for Horde preferences (was: [Kolab-devel] IMAP annotation for groupware folder descriptions)
bernhard at intevation.de
Tue Oct 9 15:02:58 CEST 2007
On Wednesday 26 September 2007 07:32, Gunnar Wrobel wrote:
> I would like to
> use the new folder type named
> From the example given in the Kolab format description I'm not
> absolutely certain if this should rather be
> In any case this folder type will be used to store client preferences,
> specifically the Horde preferences.
I am quite sceptical about this, until I have read more how the general
problem is to be solved in the future, I suggest to discuss this on
(We should also always pick one mailinglist to discuss things,
and not crosspost, except for the emails doing the transitions.)
> So far Horde used the Kolab LDAP
> tree for that but this led to the known problems of including the
> Horde LDAP schema in the Kolab server.
This would be solvable, I guess.
> There were also problems with
> the Kolab web admin when using the LDAP based preference system.
Solvable also I think.
> In addition it is probably not the most appropriate storage location
> since the preferences in Horde are bound to be changed rather often
> while a user works in Horde.
> As a consequence I would like to store the Horde preferences in a
> dedicated "Preferences" folder on the IMAP server.
We should look into more concept of where to save client configurations first,
as far as I know the Cyrus people also have made some experiments in this
regards as can be seen from the webpages.
> A draft patch for that would be ready and works fine:
> So my main question is if it okay to declare this new folder type.
> This would of course mean that I'd feel tempted to continue declaring
> more folders types such as h-links, h-filter, h-bugs, etc. These all
> represent existing Horde applications that simply need storage space
> (other than the default SQL storage). But I think I remember there was
> some opposition concerning the idea of storing additional data types
> on the server :)
Unless we are sure that this will solve the general problem,
we should not do it in my opinion. If all clients just declare new email
and folder-types for their internal data, this seems suboptimal.
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.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: not available
Size: 189 bytes
Desc: not available
Url : http://www.intevation.de/pipermail/kolab-format/attachments/20071009/1b2c9e55/attachment.bin
More information about the Kolab-format