[Kolab-devel] horde as kolab's web frontend or not
radoeka at xs4all.nl
Tue Jul 4 22:39:07 CEST 2006
Op dinsdag 4 juli 2006 11:23, schreef Jan Schneider:
> > The DataTree concept is not only used for Shares within Horde
> > though. There are other parts that use it as well for storing
> > arbitrary data values. So it would not be possible to write a DataTree
> > driver that is based on imap folders.
> Correct too. The DataTree library provides an API to access tree
> structures stored in a flat database backend. It is used for shares,
> permissions, groups (if not provided by ldap or a userland hook), and
> in some applications that use tree structures, like the photo gallery,
> the bookmark application etc.
> > I guess the most logical solution would be to extend the Share concept
> > and provide different drivers for this package. The current version
> > could be split in an abstract Share definition and a datatree
> > driver. Then it would be possible to provide a specialized kolab
> > driver that uses the IMAP folder information.
> Correct three. The Share library doesn't use drivers at all at the
> moment, it's hardcoded to use DataTree. It might be possible to extend
> it to use a Kolab driver, though you still loose the other
> functionalities provided by the DataTree API.
> > This solution would also allow to get rid of the DataTree for a
> > Kolab-oriented Horde installation.
Hmm, that sounds complicated. Do you say that the current 'share' library
only interacts with the mysql database in the horde_datatree_attributes
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.
> > Jan, should I rather post this to the horde mailing list?
> At some point we should discuss this on the Horde development list, yes.
Which lists is the best, is that: horde at lists.horde.org
Without a home the journey is endless
More information about the devel