[Kolab-devel] Anybody currently working on the kolab web interface?

[Stephan Buys]

Hi Martin,

There is no direct design information available (yes, we are Machete coders ;-)
So here goes:

1) Kolab's core design rule stays in place:
	Web -> LDAP -> backend. 		We have no intention of changing the
design, we think this is one of the best features of Kolab.
2) The kolab.conf file stays the same. (Just with a lot more options)
3) The template mechanism stays the same (expect that we have added the meta
data functionality mentioned earlier on the list)

Perl OpenLDAP Backend
-----------------------------

The effect of this is that whenever you change _anything_ on the Kolab server object
in LDAP that the kolab.conf file is modified directly. The net effect is that the Daemon
only has one place to look for information and that is kolab.conf.

This way we sidestep any synchronization issues between the Kolab LDAP object 
and kolab.conf and we can use kolab.conf as the authorative source of information.
You can still point the Daemon to use LDAP (instead of kolab.conf for everything) as it
used to be.

Major changes that you will see:
All the attributes in in the Kolab LDAP object will now also be listed in kolab.conf

Major benefits:
- We sidestep the chicken-and-egg problem whereby you cannot rewrite your templates
when you have a misconfiguration and LDAP refuses to start. 
- Templates are not rewritten upon _every_ LDAP modification. (Although this is still 
possible)

Architectural Changes:
- When you change something on the Kolab server LDAP object, the template rewrite
mechanism gets triggerred by the OpenLDAP backend (and not by the slurpd replication
monitor).

Horde Web Frontend
-----------------------

- This will be a drop-in replacement for the current Admin interface and will only operate
on objects in LDAP. We have no intention of breaking this design. (With the possible 
exception of Postfix Queue management)

- We will basically modify the Turba Address book manager to do user admin functionality.
(Ie add and remove objects in LDAP (or deleteFlag them)).





On Tuesday 23 March 2004 11:20, Martin Konold wrote:
> Am Dienstag, 23. März 2004 10:14 schrieb Stephan Buys:
> 
> Hi Stephan,
> 
> > We are going to rewrite the Web Admin interface using the Horde libraries
> > soon. We have almost completed a Perl Database backend for OpenLDAP, so
> > that the any changes on the Kolab object in LDAP gets written directly to
> > kolab.conf (in fact kolab.conf becomes the database for that object)
> >
> > The interface itself will be recreated using the Horde Framework and
> > current horde apps. Horde already has extensive LDAP based address book
> > support, so it is pretty trivial to convert the current stuff to Horde.
> 
> > Just shout out here if you want any more information...
> 
> Please make a draft of your architecture? Do you plan to directly modify 
> configuration files (e.g. main.cf from postfix)? Is the above kolab.conf 
> equivalent to the current kolab.conf?
> 
> regards,
> -- martin
> 
> Dipl.-Phys. Martin Konold
> 
> e r f r a k o n
> Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
> Nobelstrasse 15, 70569 Stuttgart, Germany
> fon: 0711 67400963, fax: 0711 67400959
> email: martin.konold at erfrakon.de
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at intevation.org
> https://kroupware.org/mailman/listinfo/kolab-devel
> 
> 
> 

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