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

[Richard Bos]

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 
http://www.horde.org/mail/

-- 
Richard Bos
Without a home the journey is endless