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

[Richard Bos]

Op woensdag 5 juli 2006 14:00, schreef Jan Schneider:
> > Hmm, that sounds complicated.  Do you say that the current 'share'
> > library only interacts with the mysql database in the
> > horde_datatree_attributes
>
> Not directly, but through the DataTree library that only has an SQL  
> driver at the moment.

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

> > relation?  If the share code is extended with a kolab driver, why would
> > one lose other functionalities provided by the DataTree driver?  I mean
> > the share library code is extended not exchanged with kolab driver code.
>
> Because DataTree is used for more than Shares, see above.

so, depending how well the kolab (ldap??) driver is written functionality is 
lost or not, right?  Why should one lose functionality if one swaps a 
database backend?  If I understood correctly you stated that the data is 
stored like in a flat file.  What I saw is that the datatree relation has 4 
attributes/fields.  When those 4 fields are supported by the kolab driver, it 
looks to me that a lot of functionality of the current datatree driver should 
be present in the kolab driver as well.

On the other hand, if kolab used only the share functionality of the datatree 
no functionality is lost.....

In case the kolab driver is actually an ldap driver, does that mean that the 
ldap horde.schema is to be extended with the datatree fields?

Jan: thank you for making time to shine a light on the horde vs kolab issues.  
It's appreciated.


-- 
Richard Bos
Without a home the journey is endless