[Kolab-devel] Declaring a new folder type for Horde preferences

[Gunnar Wrobel]

Bernhard Reiter <bernhard at intevation.de> writes:

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

I agree.

>
>> There were also problems with 
>> the Kolab web admin when using the LDAP based preference system. 
>
> Solvable also I think.

As mentioned this has been solved.

Both problem are not really much of a problem, I agree. The only real
concern might be the amount of LDAP write operations.

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

We don't have to use the IMAP driver on Kolab2/OpenPKG if you don't
like it. But from the recent discussions it became obvious that the
current kolab format specification explicitely allows declaring new
folder types. So why would that be suboptimal?

Cheers,

Gunnar

>
> 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
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~