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

[Martin Konold]

Am Dienstag, 23. März 2004 10:41 schrieb Stephan Buys:

Hi Stephan,

> There is no direct design information available (yes, we are Machete coders
> ;-)

;-)

> 1) Kolab's core design rule stays in place:
> 	Web -> LDAP -> backend.

Good!

> 2) The kolab.conf file stays the same. (Just with a lot more options)

Can you provide me with a list of intended new options?

> 3) The template mechanism stays the same (expect that we have added the
> meta data functionality mentioned earlier on the list)

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

If I understand correctly than this means the the current kolab.conf is only 
written during bootstrap but that the future kolab.conf is configurable via 
LDAP?

> This way we sidestep any synchronization issues between the Kolab LDAP
> object and kolab.conf

I don't understand this. 

> and we can use kolab.conf as the authorative source 
> of information.

Hmm, sofar the LDAP directory was the only authorative source of information. 
What do you can with kolab.conf in between? Why do you think it solves 
synchronization issues?

> You can still point the Daemon to use LDAP (instead of 
> kolab.conf for everything) as it used to be.

I still prefer the old behaviour as long I dont understand the advantages of 
the new behaviour.

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

You have a partial point here but I think that the problem can be solved 
differently. Sofar I am not aware of a problem which would have been avoided 
by your new approach.

> - Templates are not rewritten upon _every_ LDAP modification. (Although
> this is still possible)

Templates never got rewritten but for simplicity we regenerated all 
configuration files (based on templates + LDAP data) every time a change 
happened. 

With the old scheme it is of course possible to avoid this and optimize to 
only write those files which are actually affected by a change in the LDAP 
directory.

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

What is your OpenLDAP backend. This terminology is confusing to me as the 
OpenLDAP people define the OpenLDAP backend very differently. (meaning the 
actual storage machanism e.g. gdbm, SQL,...)

http://www.openldap.org/lists/openldap-devel/200306/msg00076.html

How does the your backend know that something changed in the directory. 

Please note that we only use the slurpd replication monitor in order to notice 
that something changed we dont use it to transfer data.

> Horde Web Frontend
> -----------------------
>
> - This will be a drop-in replacement for the current Admin interface and
> will only operate on objects in LDAP.

Good!

> We have no intention of breaking this 
> design. (With the possible exception of Postfix Queue management)

How do you intend to make web based queue management?

Which user/permissions does the web interface have? 

Does it have root permissions?

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