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

[Jan Schneider]

Zitat von Richard Bos <radoeka at xs4all.nl>:

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

Sure, everywhere where users or admins are setting permission, e.g. on  
calendars or applications.

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

Rather like filesystem ACLs, but yes, similar like that. And no, a  
user is not always authenticated, if he isn't, he's a guest. Admins  
can allow guest access to applications, and users can allow guest  
access to shares like calendars. This way you can have a public  
calendar for example, read-only accessible by everyone.
User shares are resources like calendars, tasklists, notepads etc.

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

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

No, you would have to choose once between using DataTree or Kolab/IMAP shares.

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

There I several points I still see valid.
Regarding security: administration users are still used both for LDAP  
and IMAP access. As Gunnar explained it's probably not necessary for  
LDAP but still for IMAP to allow IMAP annotations on shared folders.
Regarding stability: the current synchronization that happens between  
the Kolab shares and Horde DataTree/Shares is error prone, but could  
be solved by implementing a Kolab driver for shares in Horde.
Regarding performance: The Kolab code in Horde is not using any IMAP  
cache at all at the moment.

Jan.

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