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

[Richard Bos]

Hello Jan,

Op donderdag 6 juli 2006 12:51, schreef Jan Schneider:
> For the case that people are completely lost what we talk about here,  
> this is a short summary:

Thanks a lot for the summary.  It made things much clearer indeed!

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

So far so good.  BTW: is it possible to see the matrix you mentioned above in 
horde.  Or is it just there? With the latter I mean that the horde-admin just 
configure the tabs, configure what people are allowed to use and not, and as 
such he uses the DataTree and Permission libs.

> Finally there is the Horde Share library that is built on top of both  
> the DataTree and the Permission library. 

Understandable.

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

Do you have an example?  What is a user share?  And for which application is 
this valid?  In case something is shared, how is that done compared to e.g. a 
unix file system, files can be shared using the group bits correctly 
(-rw-rw-r--). Is this done similar in horde?  So a user share could be 
configured like:
sred/sre-/sr---/s---; meaning show, read, edit, delete for the user,
show, read, edit for the group, show, read for the guests and show for the 
authenticated?  What is actually meant with authenticated?  Isn't a user 
always authenticated in horde?

> The permissions are used to keep track of the access permissions to a  
> single share.

With permissions do you refer to the matrix of show/read/edit/delete 
permissions and users/groups/guests/authenticated.  Or do you refer to each 
of those indivually?

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

Is it possible to map the imap annotions/permissions 1 to 1 with the horde 
permission matrix (Gunnar might know this)?

Would it be possible to extend the horde share library in such a way, that it 
knows it is dealing with an kolab shared folder (perhaps by an adding, at the 
right place, a field 'share_type' that can have the 
values 'native(horde)/kolab/othergroupware')? .  In the kolab case the horde 
share library should bypass the DataTree and Permission libs and should use a 
kolab library instead.  This added part to the share library should than use 
the data from imap folder directly instead of the data provided by the 
combined datatree/permission library, but still respecting the DataTree and 
Permission libs api.

After this long discussion, I don't know anymore what's the reason the kolab 
developers hesitate to use horde.  I thought it has to do with security.  In 
case it has to do with security would this security problem be resolved using 
the extented share library that I mentioned above (if feasible at all of 
course).

-- 
Richard Bos
Without a home the journey is endless