[Kolab-devel] Re: Problem with imap folders and Horde

[Stuart Bingë]

Hello everyone,

On 6/14/05, Martin Konold <martin.konold at erfrakon.de> wrote:
> Am Dienstag, 14. Juni 2005 21:31 schrieb Bernhard Reiter:
> 
> Hi,
> 
> > I fears are about this special application
> > saving session details of Horde into ldap variables
> > on a regular basis.
> 
> Yes, this would be total abuse of the LDAP directory. But I see no point in
> putting session data in the LDAP directory at all. The plain filesystem is
> much better suited for this purpose. Actually putting the session data
> in /tmp/ is the default in php.

The DataTree system is entirely separate to the Session system within
horde, so there will be no session data stored in LDAP with the LDAP
DataTree driver. By default Horde uses the PHP session handler, which
as Martin said stores the session data on the filesystem.

> > I mean that if you need a regular database with a lot of writes,
> > ldap is not the best for you. It is optimised for read access
> > and has the OID limitations.
> 
> And in addition LDAP is incoherent by definition.
> 
> But OpenLDAP is very well suited for user and application specific
> configuration/preference data.

That's just what the DataTree system stores - user and application
specific configuration/preference data :-)

To be specific, it mainly stores information about the list of shares
(groupware resources) for each user and the permissions on each of
these shares - these objects change very infrequently, and as such I'd
say 95% of all operations on the objects would be read operations.

The issue over the master/server setup is a bit more complicated,
however for the initial release of the LDAP DataTree driver we'll be
restricting it to read from and write to a single server, which in
terms of a Kolab installation would most probably be the users' home
server. This may not necessarily be a problem, depending on how Horde
is setup across the Kolab infrastructure, but it may break down with
several Horde installations across the hierarchy and a user trying to
access their own data from a different Horde instance. But anyway,
this problem is for a later date, if we even need to address it.

Cheers,
-- 
Stuart Bingë