[Kolab-devel] Declaring a new folder type for Horde preferences (was: IMAP annotation for groupware folder descriptions)

[Bernhard Reiter]

Hi Gunnar,

On Wednesday 26 September 2007 07:32, Gunnar Wrobel wrote:
> I would like to
> use the new folder type named
>
>  h-prefs
>
> From the example given in the Kolab format description I'm not
> absolutely certain if this should rather be
>
>  kolab.h-prefs
>
> 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 
kolab-devel@ first.
(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:
>
> http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE_CVS/file/tip/framework/HK-GW
>-Prefs-Kolab_IMAP.patch
>
> 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.

Bernhard

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20071009/1b2c9e55/attachment.sig>