[Kolab-devel] horde as kolab's web frontend or not
radoeka at xs4all.nl
Wed Jul 5 22:44:45 CEST 2006
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.
Without a home the journey is endless
More information about the devel