[Kolab-devel] Kolab Bootstrap redesign

[Stephan Buys]

Just to make one thing clear:

This is not to be construed as Kolab v. 2.0. This is the experimental branch from
Code Fusion cc. These are changes that we feel is necessary to meet our 
own needs. There is also no clear migration path or anything like that. 
Chances are very good that these changes will make it into OpenPKG Current 
and subsequently onto ZfOS. (It should be stable enough for production use...)
You can still use the original engine with ZfOS, check the obmtool.conf script
for info on how to do this... At the moment our engine is the default version for
OpenPKG 2.0, thanks to Thomas Lotterer the maintainer of the site.

Kolab 2.0 will probably be Proko2, but that is left to be seen. Proko2 might become
Kolab 3.0. Any decisions on a "new approach" or "new version" I happily leave 
in the hands of the maintainers, if they feel this version is stable enough and 
a migration path has been defined we can label the ZfOS version of Kolab as 
Kolab version 2.0.

On Wednesday 10 March 2004 18:32, Ian Reinhart Geiser wrote:
> On Wednesday 10 March 2004 10:12 am, Stephan Buys wrote:
> > You will notice that this implies the ability to dynamically map
> > your users, contacts and the Kolab object to different places in
> > LDAP.
> I think this is a core feature for us.  Since we are integrating kolab into
> existing infrastructures we require more to make kolab look like their ldap
> schema than to manhandle theirs into our schema.
> 
This is already supported in our version of Kolab on ZfOS, check out kolab.globals
to see the possible configuration values. Also look at the perl-kolab modules.

> This should simplify my hack to get mailing lists and aliases to work
> properly.  

Care to contribute any of this work to the project? We dont use the virtual maps
for aliases anymore, we use LDAP lookups (also already in ZfOS)

> Requiring the mucking with the perl script to extend kolab is a 
> nightmare.  Perl is ill-suited to maintain over a long term, so the less we
> need to rely on that the better.  As long as the real data can be kept in
> LDAP and filled into templates I feel that is the best approach.
>
If you want to look at an extensible, modular backend have a look at the Code
Fusion version of Kolab. It has a completely different codebase derived
from the original Kolab scripts. Perl should be and is more than adequate for now.
 
> The other issue is migration of current Kolab to this "new" approach.  Since
> Kolab 2.0 has been quite tight lipped about any migration, I'm very curious
> if this new method will make migrations less painful.  Ideally kolab 1.0 ->
> 2.0 will be trivial to migrate, but due to the hacks I have had to include
> for spam filtering, anti-virus, webmail, sieve editing and group aliases I
> may be in for some fun, but thats my fault ;)
> 
We would surely appreciate any contributions to the project. Please dont
mistake our silence about this stuff as being "tight-lipped". 

> Cheers
> 	-ian reinhart geiser
> 

-- 
Stephan  Buys
Code Fusion cc.
Tel: +27 11 391 1412
Mobile: +27 83 294 1876
Email: s.buys at codefusion.co.za

E-mail Solutions, Kolab Specialists.
http://www.codefusion.co.za