[Kolab-devel] Kolab administrative web interface: why not using horde?

[Bernhard Reiter]

Hi Fabio,

On Thursday 03 March 2005 18:16, Fabio Pietrosanti wrote:
> i have to say that kolab administrative interface is quite uggly even if
> it have the basic functionality (groups management could be a great
> addition!).

I am assuming that you refer to handling and funcationality?

> Horde is the webgui of kolab and the dev effort for the "web" component
> will be done on horde.

We hope so, the main problem to solve as I was informed
is the speed problem that mainly arises from the direct imap use
without extra cache on horde.

> Kolab web administration if i understand correctly do two basic stuff:
> - read and write ldap directory
> - create mailbox, create shared folder, set permission on cyrus server.

Most of that stuff is done by the kolabd components.
And it makes sense to move even more configuration in there
and let it do more stuff to make the server completely independent
of the ldap client used.

> Horde right now work well for ldap administration and theorically could
> already add users to kolab server.

I haven't checked how good horde's ldap client is.

> Horde support the cyrus administration within the "composite" driver.

What is the permission situation here?
Most webbased administration interfaces will have huge portions of code run 
as root. Kolab tries to avoid this for security reasons.
I don't think that the major design that the kolabd reacts when the ldap changes 
shouldn't be changed for the administration of cyrus and other parts.

> A composite driver Cyrus/Ldap could be very easy to be written and could
> do all kolab user administrative functionality.

As said before: I have not taken a deep look into that part of Horde,
so I don't know what a composite driver would be here.

> Horde will have within months completed the ldap datatree (my company
> will sponsor it) so it will work completelly without the need of a SQL
> backend.

It is good news that Horde gets independend of an SQL RDBMS,
but will it use ldap as database then? This would be a major design
difference as other kolab clients do you their local cache
and the ldap in the kolab server is mostly for read operations.

> Horde in future will probably become part of the kolab distribution,
> packaged along with cyrus, postfix, openldap, apache, etc, etc.

Currently the plan is to keep it seperately as extension,
because we expect Horde to hit performace in setting with more users.

>
> My question/proposal is:
>
> Why the need to rediscover the hot water when someone already did it and
> we could just need to put the "lemon" to have lemonade (Kolab server +
> Horde Web Administration)?
>
> I'm sure that there are a lot of good motivation to use an indipendent
> web administration interfaces but i think that horde administration
> could be easily extended to do all "user" administration stuff of Kolab.

Well, why not have another possibility for a ldap client
that can administer kolab?
For the reasons above it seems good that the bare bones kolab webadmin
exists as some people do not need a web client at all
(most  users have a better GUI experience with native clients,
that can even be used offline.)

> We could also think to keep the kolab administration interface for all
> the "infrastructure" settings, leaving on horde all other "user
> administration" stuff like "add users, add group, add alias, add
> addressbook, add administrator, set permission", etc, etc

Well you can add "groups" in the kolab webadmin, they are called:
distribution lists and end up being a groupOfNames LDAP object.
They can be used to set the automatic invitation handling for instance
or to give our permissions, because the are mapped to imap groups.

If we had a real multidomain feature we probably wanted to handle
those groups of users in different ldap subtrees. This is a major operation.
It would be cool it somebody would fund or do that step for Kolab.

Regards,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050303/9e8b683f/attachment.p7s>