[Kolab-devel] horde as kolab's web frontend or not

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at gentoo.org>:

> Richard Bos <radoeka at xs4all.nl> writes:
>
>> And in case of kolab the ldap database should be used to store the data is
>> that right?  And the reason for that is, that the user's credentials can be
>> used instead of the database user only (which is considered a security issue
>> by the kolab developers, is that correct)?
>
> I tend to disagree on that. You could certainly exchange the sql
> driver against a ldap driver. And you are right, you would not loose
> any functionality through that.

Correct.

> But I suggested to get rid of the DataTree in its entirety because it
> is MAINLY used for share data. All of the share specific information
> can be directly stored on the IMAP folders themselves (owner,
> permissions, name). So there is no need at all for having a database
> backend, neither sql nor ldap.

This is debateable, but I agree that it makes a lot of sense to  
implement an IMAP/Kolab-Share driver that reads and stores share  
information and permissions from the IMAP folders.

> My impression has also been that this would greatly simplify the way
> kolab shares are handled. Right now this is a tangled mess of hooks
> that try to keep the data in the DataTree in sync with the IMAP
> folders. If I'm not completely mistaken this can be avoided.

Exactly.

> This would need an IMAP oriented Permission driver and a Kolab
> specific Share driver.

I don't follow you why we would need an IMAP permission driver and how  
that should work.

> The functionality that will be lost in this transition:
>
>  1) DataTree functions other than Shares
>
>  2) Some extensions to the permission system that cannot be supported
>  by an IMAP driver.

See above, I don't see how an imap permission driver should work.

For the case that people are completely lost what we talk about here,  
this is a short summary:

Horde has a so called DataTree library that provides an API to random  
tree structures. The only driver that is currently implemented for  
that library is an SQL driver that maps the tree structure to a  
database structure. An LDAP driver for the DataTree library doesn't  
exist yet but probably would make sense.

The Horde Permission library is built on top of the DataTree library  
and is used to set permissions on arbitrary objects, organized in a  
tree. These objects are e.g. applications, application features,  
application objects etc, i.e. you can limit access to applications,  
the number of items in an application and so on. Permissions  
themselves are usually represented as a matrix of  
show/read/edit/delete permissions and users/groups/guests/authenticated.

Finally there is the Horde Share library that is built on top of both  
the DataTree and the Permission library. The DataTree library is used  
to organize the hierarchy of shares, i.e. you have the application in  
the root node, the users' shares in subnodes and so on. The  
permissions are used to keep track of the access permissions to a  
single share.

The only concept that has an equivalent in Kolab are Shares which are  
actually shared IMAP folders and Share permissions which are stored in  
IMAP annotations.

>  3) Stuff I overlooked :)
>
> 1) is not really a problem since nobody would prevent you from still
>    having a mysql db and keeping your datatree in there if you really
>    need something of the additional functions. From what I saw so far
>    I have nothing other than shares using the datatree.

If you can abandon the option to use permissions other than share  
permissions, SyncML support, and applications that use DataTree for  
their application data like the bookmark manager or the forum, yes,  
you don't need the DataTree library.

> 2) So far there is only the option to limit the number of items
>    (events, notes, addresses,...) that would get lost for kolab. Not
>    much of a problem since the number of items a user can have is
>    limited by a quota if desired.
>
> 3) Probably a few things :)
>
>> Jan: thank you for making time to shine a light on the horde vs   
>> kolab issues.
>> It's appreciated.
>
> And thanks for writing great code. The whole horde stuff is really
> well readable which is a delight.

Thanks.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/