[Kolab-devel] LDAP attribute kolabHomeServerOnly

[Gunnar Wrobel]

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> * Gunnar Wrobel <wrobel at pardus.de> [20090416 14:16]:
>> Guess I'm somewhat slow in reviewing code these times as these are  
>> changes from February:
>>
>> http://kolab.org/pipermail/kolab-commits/2009q1/009163.html
>> http://kolab.org/pipermail/kolab-commits/2009q1/009165.html
>>
>> Can you explain in more detail why this LDAP schema change was  
>> necessary and what the functionality
>> is about? My gut feeling would be that a new LDAP attribute might  
>> be too much and I feel we already
>> packed too many such attributes in our schema. So I felt the need  
>> to understand this change.
>
> Regarding the functionality:
>
> Not all IMAP clients need the dummy inbox on the other servers and
> you only need it anyway if users on one Kolab server need to access
> shared/published folders on a different Kolab server in a
> master/slave setup.
>
> The functionality was requested by a client who does not want to
> clutter the IMAP spool directories with directories which are not
> used in his setup.
>
> Regarding the LDAP change:
>
> It is only a schema extension, so it will not affect existing
> installations. The reason for adding it to LDAP is to have identical
> behavior on all servers. The reason for adding it as a user
> attribute instead of a global attribute is that you still might want
> to have certain users with mailboxes on all servers, because you
> know they have IMAP clients needing the additional inboxes.
>
> Like some other LDAP attributes it is not wired to the web admin
> interface, so that does not even get cluttered with bells&whistles
> that most people do not need.

Hm, that is true. But the schema itself gets just another attribute  
linked to some functionality that is not really obvious.

I've raised this issue before and I'm actually still opposed to adding  
new attributes for functionality offered by a single client  
application. I'd rather have an attribute "kolabdPreferences" that can  
occur multiple times and carries values such as  
"home_server_only=true". There are other attributes just relevant for  
postfix and new attributes have been proposed solely for features one  
might add to the web admin. I consider this a broken approach.

I know others disagree and maybe new attributes are indeed necessary.

I'd like to ask though that they get more documentation in the schema.  
There are already now many attributes where I don't know what they  
were meant for and if there are Kolab server subsystems that might use  
this attribute. Yes, one can grep through the code in Kolab CVS to  
find locations where the attribute may be used. But I don't consider  
that optimal.

Another suggestion: If we really want to add such attributes to our  
object classes which are only relevant for a single LDAP-aware  
application we might group these in their own object class (e.g.  
kolabPreferenceKolabd) as a supplemental object class to  
kolabInetOrgPerson.

Cheers,

Gunnar

>
>> I probably overlooked the references where this was explained in  
>> more detail so a hint would be
>> great. Thanks!
>
> There was no public discussion about this.
>
> Regards,
> Thomas Arendsen Hein
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090419/b35baa69/attachment.sig>