[Kolab-devel] horde as kolab's web frontend or not
jan at horde.org
Fri Jul 7 11:19:31 CEST 2006
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
> 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.
>> 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 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
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.
Do you need professional PHP or Horde consulting?
More information about the devel