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

[Richard Bos]

Op vrijdag 7 juli 2006 11:19, schreef Jan Schneider:
> > After this long discussion, I don't know anymore what's the reason the
> > kolab developers hesitate to use horde.  I thought it has to do with
> > security.  In case it has to do with security would this security problem
> > be resolved using the extented share library that I mentioned above (if
> > feasible at all of course).
>
> There I several points I still see valid.
> Regarding security: administration users are still used both for LDAP  
> and IMAP access. As Gunnar explained it's probably not necessary for  
> LDAP but still for IMAP to allow IMAP annotations on shared folders.

But why does a client like kmail not need the administration user (in case of 
the iMAP annotations, I assume that kmail supports IMAP annotations on shared 
folders)?

> Regarding stability: the current synchronization that happens between  
> the Kolab shares and Horde DataTree/Shares is error prone, but could  
> be solved by implementing a Kolab driver for shares in Horde.

Okay, clear.

> Regarding performance: The Kolab code in Horde is not using any IMAP  
> cache at all at the moment.

Does this really make a difference in case the imap folder resides on the same 
system as the webserver?  I believe that this can be added later to horde, 
after the other points described above by Jan have been solved.
Dimap is probably very usefull in case the imap server is a different one and 
the user uses the agenda groupware functionality.

What about scalability?  Is it easy to add just another horde server, or 
should I say slave?  So, there should actually be 1 horde master and many 
replicated slaves (like ldap indeed).


-- 
Richard Bos
Without a home the journey is endless