[Kolab-devel] enlargement of kolab ldap schema for asp service

[Gunnar Wrobel]

Hi Thomas, hi Bernhard,

Bernhard Reiter <bernhard at intevation.de> writes:

> Hi Thomas,
>
> On Monday 23 July 2007 19:04, Thomas Börnert wrote:
>> i plan to use kolab as a asp solution and need some additional
>> ldap attributes.
>>
>> i need the new attributes only for the web administration frontend.
>>
>> i'd a offline discusstion with gunnar wrobel and he recommends to
>> use a generic ldap attibute as "kolabPrefs" or "kolabWebadminPrefs".
>> in this case there this is a generic solution for all other improvments,
>> and it is not necessary to extend the ldap schema for each additional
>> function.
>

The original discussion has been in German and I'll just translate my
original response into English. 

Let me summarize the original problem first:

The ideas proposed by Thomas were mainly concerned with usability
features for the kolab-webadmin. He desired to store a number of
preferences within the LDAP tree.

> can you summarize the whole proposal of adding these attributes
> again?

Basically your proposed features are centered around the usability of
the kolab-webadmin. Most features you suggested seem to be useful
indeed. What do envision as difficult though are any modifications to
the Kolab-Server-LDAP-Schema. I'm no LDAP-Expert but as far as I know
these Schemata should be as stable as possible. Once we start
introducing the preferences of external tools into the schema we will
have to modify it rather frequently.

Something like the "uidPrefix" you proposed would be highly specific
to the kolab-webadmin and most users might not use it at all. I regard
adding a new attribute into the schema for that as too complex.

I'd rather propose adding a generic attribute such as "kolabPrefs" (or
more specifically "kolabWebadminPrefs") and store generic
variable/value pairs within this attribute. So you would store
something like "uidPrefix=pop-22003" as a base64 encoded string within
the LDAP-Tree. This way storing parameters for a specific external
tool would be rather flexible and would not necessitate modifications
to the LDAP schema.


This was my original proposal and I stil believe it make sense to
introduce something like that into the k=kolab object. I'm actually
more in favor of a general "kolabPrefs" attribute since it could be
used by just any external tool we want to modify so that it works
together with the Kolab-Server-LDAP database. 

Cheers,

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

    >> Mail at ease - Rent a kolab groupware server at p at rdus <<

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