[Kolab-devel] Extending Kolab

[Gunnar Wrobel]

Bernhard Reiter <bernhard at intevation.de> writes:

> On Friday 02 May 2008 14:51, Gunnar Wrobel wrote:
>> >>  > We could think about defining a "playground" OID subtree, if there is
>> >> none > in the OID scheme already. (Does something know out of the top of
>> >> their head?) > Before this I would want to document the use of Kolab's
>> >> privat OIDs. > I have already the start
>> >>  > http://wiki.kolab.org/index.php/Directory_Service_Schema
>> >>
>> >>  Is there any specific reason for having new OIDs for such
>> >>  configuration variables? This seems extremely cumbersome as it always
>> >>  requires a schema change for any application we might wish to
>> >>  configure over the LDAP tree.
>
> "extremely cumbersome" is not the right attribute ... as Alain correctly 
> points out
>
>> > Extend the LDAP schema is very easy, just add your new attributes in
>> > the schema file and restart ldap. 
>
>> I was thinking of adding new attributes in the Kolab schema that gets
>> delivered with the default distribution. Meaning changes within Kolab
>> CVS and this takes more effort. For local hacks this is of course
>> easy.
>  
> Adding and changing attributes too lightly is a call for trouble, especially 
> in upgrade situations. So a little resistance is good. And a little it is.
> If the bar is to high at the moment, we could lower it by a set of 
> instructions and we might consider a playground subtree of the Kolab OIDs.
>
> The whole idea of LDAP is to be able to control the variables and their 
> contents. So if you have a changed or new OID, yes you should do a new number
> and put up a real definition of the type and semantics. The rules out implicit 
> definitions, but again I believe this is a good thing when being consistantly
> in LDAP. Overal I think LDAP and is overdesigned, but the abuse would add to 
> the complexity from my point of view, making it worse.

Okay, but then we shouldn't be talking about using LDAP at all for
adding extension packages to the Kolab server. If we want to add apps
like postgrey, munin, squirrelmail etc. and some or most of these apps
need additional configuration variables we could store them in
standard configuration files on the server. They could be modified by
the system admin but not via the webadmin.

I think the only reason why people get the idea of storing such
variables in the LDAP tree is because the "k=kolab" object already
exists and is doing exactly this kind of thing. It was just never
meant to scale to more than the kolab server core packages.

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

-- 
______ 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 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~