[Kolab-devel] Kolab 1.1 (2.0?) wishlist

[Stephan Buys]

Hello all,

As per previous discussions and upon request I have compiled a list of some
changes that I would like to see in Kolab. All discussions, flames and 
reprimands will be ignored ;-) (just kidding!)

Please send in your lists as well, I could compile a wishlist webpage for 
general discussion/public review if required.

Any suggestions on how to best co-ordinate a wishlist would be welcome.

Best regards,
-- 
Stephan  
-------------- next part --------------
Kolab Wish List/Development Goals
---------------------------------

1) Decoupling Kolab in LDAP

   At this stage the Kolab server is fixed as k=kolab under the base DN.
   Also users are fixed as inetOrgPerson under the base DN and Address book
   entries under cn=external under the base DN.

   I propose that a: The location of the Kolab server should be configurable.
   Any entry of the correct objectClass should be configurable as a Kolab
   server. Perhaps kolab.conf file should contain the dn of the Kolab server for
   that specific hierarchy.

   Secondly. It should be configurable - either through the kolab.conf file, or
   through LDAP - to add any arbitrary DN as a location for users and addresses.
   Possibly there could be a user_dn and address_dn attribute for the Kolab
   object.

   Example (in LDIF format):

      dn: cn=mail-server1,dc=example,dc=com
      objectClass: kolabServer
      user_dn: ou=sales,dc=example,dc=com
      user_dn: ou=admin,dc=example,dc=com
      user_dn: ou=mktg,dc=example,dc=com
      address_dn: ou=contacts,dc=example,dc=com
      address_dn: ou=important,dc=example,dc=com

   This Kolab server has 3 user ou's and 2 address ou's.

  -Advantages?

   Using this scheme several Kolab servers could exist within one LDAP tree.
   Organization wide directory replication can then be facilitated.
   Changes/Updates are done on the Master OpenLDAP server and then propogated
   throughout the organisation using slurpd replication.

2) Decoupling of Kolab from /kolab

  IMHO there should be a configuration file in /etc (maybe kolab.conf?) which
  should point to the kolab instance. The kolab backend should read the file
  and then locate the Kolab instance accordingly.

  This will take a lot of work but could potentially please a lot of people
  who believe is the Linux FSH. Personally I would like to see Kolab live under
  /opt/kolab.

  This is maybe a lot of work with a lot of files that need to be rewritten
  during installation.

3) Refactoring of Kolab backend.

  IMHO the kolab backend should be renamed kolabd and should be move to
  /kolab/sbin or something similar. I just dont like the fact that an
  executable is living under a configation folder.


4) Bye bye virtual file rewriting

   With the current version of postfix that we are using LDAP support is enabled.
   This allows us to do virtual lookups using LDAP. We do not need to rewrite
   the virtual files and use hashes. It is possible to avoid binding to the
   LDAP server, which speeds up searches quite a bit.

   This solution works quite well with good performance.