kolabd package available in Debian sid

[Fabio Pietrosanti]

Bernhard Reiter wrote:
> Richard,
>
> On Sat, May 06, 2006 at 03:33:59PM +0200, Richard Bos wrote:
>   
>>> The estimation of many developers is that Horde is probably very hard to
>>> fix because of design problems. Fixing Horde or using different components
>>> will be a lot of work.
>>>       
>
>   
>> is it possible for you to point out the problems that you see with respect to 
>> horde working together with kolab?  Looking at the bug reports in the horde 
>> bugdb (http://bugs.horde.org/ fill in 'kolab' in the summary field), there 
>> aren't too many issue's.  Especially not design issue's...
>>     
>
> I have had several developers that have deeply looked into the code say
> that they cannot bring Horde as Kolab Client into a stable, maintainable state.
> It supposetly is more inexpensive to write a new webclient.
> I have not a detailed list of technical reasons and it probably
> would be a major piece of work to produce them.
>
> What my understanding of the design problems is:
>
> 	a) the use of the database versus Kolab's design of imap folders.
>            It will create almost unsolvable sync issues and hurt stability.
>            And if the code is spread throughout
>            Horde, this will be hard to change.
>   
All the kolab data is already stored in imap.
Most of the horde preferencies are instead stored in the LDAP user profile.
This only other data that would completely remove the needs of SQL db
depend on the availability of "ldap datatree" driver which is estimated
a few days to be implemented.
In such way all the "kolab" data will continue to be stored in IMAP and
only the horde preferencies will be available trough LDAP directory
without the need of SQL DB.

And, if by design we doesn't want to store any preferencies by using
horde ldap schema, i don't think that would be so complex to create a
"datatree" and "preferencies" driver for horde that use as a backend an
imap folder. Perhaps 7-14 days?

> 	b) Horde needs higher privileges. This is in contrast
> 	   to the Kolab-Webinterface that only works with the 
>            priviledges of one user. If true, this would hurt the security.
>            Note that database application are often designed this way,
> 	   Kolab can do differently which is a plus.
>   
Also this approach could be changed easily with few days work by using
the horde framework to adapt certain functionalities of Kolab driver of
various horde applications.

> This means design incompatibilities that say nothing about how good 
> Horde is when used standalone.
>   
By using the previously described fix horde is "the" candidate for a
webclient interface, obviously imho.


A single google summer of code initiative would make horde a serious and
stable web client for Kolab imho.