[Kolab-devel] RFC - The future development direction of Kolab

[Ingo Steuwer]

Hi,

Am Donnerstag, 21. Juni 2007 22:04 schrieb Bernhard Reiter:
> Hi All,
>
> On Thursday 14 June 2007 15:29, Stephan Buys wrote:
> > Kolab's single greatest feature for me is the fact that it was designed
> > around a LDAP directory.
>
> to generalise it is a directory service which does the identity management.
> The idea of such a directory service to also make it a configuration
> service directory is good and not quite recent.
> However it seems that there are practical problems with this,
> especially with LDAP. The idea that a really cool set of attributes
> with common usage gets standardised has not come true to some extend.
> The password problems is a glowing example for this.
> Application just do not work togehter well enough.
>
> Many customer where we have been already have some approach to a identity
> management and they need Kolab Server to be modular, cooperating with
> eDirectory, activedirectory, fedora directory and so on.
> OpenLDAP itself did not strike me as a very good implementation.

I think the main different is the approach - your examples are all a lot more 
than pure LDAP, eDirectory and Active Directory are "only" LDAP-frontends for 
an older identity backend (AD still uses a NT-like SAM database). OpenLDAP 
for its own is just "pure" LDAP.

> One step that I would like is to make Kolab Server more modular here.
>
> > The role that kolabd fullfills is really versatile
> > and can be used beyond just groupware/email:
> >  - With the KOLAB_META template mechanisms it is possible to deliver:
> >         * Samba integration
> >         * Asterisk integration
> >         * LDAP logons for Linux clients
> >         * Auto-configuration (via LDAP) of Kontact for first time users
> > using LDAP logons
>
> I have seen people using LDAP for more as well. You can implement
> a reliable queing concept with it.
>
> > ** Shouldn't we consider making kolabd a first-class citizen? Its own
> > sub-project, tightly coupled with LDAP/slurpd and able to handle much
> > more than just postfix/cyrus/etc? It could be the basis for an
> > enterprise-wide directory/central user store managing services as needed.
>
> The real use of kolabd is the contents this means the contents of the
> templates, the attributes and all this. Actually kolabd already is quite
> versatile.

I fully agree to focus on groupware usability and features, which are the main 
goal of Kolab. So let me add some ;-)

> If you would ask me where to take Kolab in the Groupware area,
> I would say:
> a) solve the mobile client problem, g.e. evaluating a funambol connector.
Yes, a documentation "yes it works" would do very much here. Integration of 
Blackberries is AFAIK technically different but also interesting.

> b) integrate a good email archiving solution
> c) make provisions for a client integrating accounts from three different
>    Kolab Servers so that the user is in control of his or her data.
Should this include multi-server-hosted domains? I'd like to see 
some "shared-folder-sync" between two kolab servers sharing the users of one 
domain.

> d) Add soa capabilities. Best with a new set of clients based on
> python-kolab. Also to add testing.
> e) make a better automated test setting. We are growing compatible clients,
>    so this is getting increasingly important.
> f) solve document management, does this mean inventing good ids which work
>    for referals. Doing this with offline clients is a challenge.
>    What about signatures and document life time management?
> g) Make it capable of better CRM funcation, solve the gap here between
>    our user centric and pim centric approach and the data mining
> capabilities of large "contact" databases.
> h) Make email encryptions to fully be usable in iTIP emails and in the
> storage format. This would take protection to a new level.

A very important thing in my point of view would be a second "full featured" 
Windows client beside Outlook, idealy an open source based. Possible 
candidates are a Thunderbird Connector (how stable is it, does someone has 
some expiriences?) or Kontact for windows which should be possible with 
KDE4/QT4.

Cheers
Ingo

>
> Bernhard

-- 
Ingo Steuwer           Projektmanagement        steuwer at univention.de
Univention GmbH        Linux for your Business  fon: +49 421 22 232-43
Mary-Somerville-Str.1  28359 Bremen             fax: +49 421 22 232-99
                       http://www.univention.de