kolabd package available in Debian sid

[Jan Schneider]

Zitat von Andreas Gungl <Andreas.Gungl at osp-dd.de>:

> Am Mittwoch, 10. Mai 2006 19:42 schrieb Jan Schneider:
>> > On Sat, May 06, 2006 at 03:33:59PM +0200, Richard Bos wrote:
>> > 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.
>>
>> Horde does not have an inherent database driven design. Quite the
>> contrary, it has a driver based design. This made it possible to write
>> Kolab drivers for the several applications so quickly. There is this
>> DataTree thingy that still causes a lot of headaches because it's the
>> last remaining database dependency in Horde, but solutions for this
>> problem have already been discussed in the past.
>
> The database dependency is ugly. At first, you have to install MySQL on a
> machine only for a small thing which has nothing to do with the actual
> functionality of the server. (I'm aware that I could use a second machine
> for Horde besides the Kolab server, but that's something else but a
> consolidation, right?)

I think we all agree that this dependency has to be removed mid-term.  
The solution would be to develop an LDAP driver for the DataTree  
library. There have been a few attempts to sponsor such a  
developement, but unfortunately they all fizzled out.

>> > 	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.
>>
>> I'm not sure if this is true, and I'm wondering if this is really a
>> general design issue in that case. I guess it could be solved.
>
> It is at least a security flaw. It would be better to let the user log in
> using his own credentials (checked against LDAP). A related problem was the
> ability to log in both with the Kolab UID and primary email address. There
> has been an attempt to fix that, but I don't know about the result. I've
> adviced our colleagues to use the primary email address, because otherwise
> they may get unpredictable results when accessing their data.

http://bugs.horde.org/ticket/?id=1317

>> I'm not trying to sell anything, but I really doubt that it makes any
>> sense to write a custom web frontend for Kolab, even if it ties much
>> better into the server. Horde already provides all features that the
>> Kolab server offers, without installing a Kolab server. I would be
>> insane to start from scratch instead of ironing the few remaining
>> wrinkles out.
>
> What makes me wonder is how few interest has been shown from the Horde team
> when I submitted tickets and patches. There still is a good chance for
> Horde to become THE web based client for Kolab - with a lot of publicity.
> Well, at least even you, Jan, are reading this list. I see it as an
> improvement. But it's still not what I understand as constructive
> cooperation between projects. AFAICS Horde still can't use the personal
> contacts from a Kolab account. As another example,
> http://bugs.horde.org/ticket/?id=1659 is still open although there should
> be no problem to fix it for an experienced PHP developer (unlike me). So,
> yes, I'm disappointed and I understand if others are as well.

The problem is that both Kolab and Horde are pretty complex and large  
software projects. To integrate them flawlessly requires detailed  
knowledge about both. Beside that, both projects are lacking active  
developers (AFAIK, I can only speak for the Horde Project but I have  
that impression on Kolab too). Developers of both projects are already  
buried with work to improve and fix their software *alone*. It's not  
that there is no interest from Horde, though we are not out for  
publicity for being a Kolab client. But none of the Horde developers  
is using Kolab anywhere, so we depend on outside developers like  
Stuart Binge or Tobias König to dive into the details.
All this could change if someone is going to pay a Horde consultant to  
work on the integration (http://www.horde.org/consulting/). I already  
talked about such a cooperation with Till Adam two years ago, but  
unfortunately this didn't lead to anything either.

> As has been said, we're using Horde despite the flaws. I've decided to keep
> my hands off of the Horde files. ATM we still run a CVS copy from about one
> year ago (June 1st, 2005). Perhaps I'll try a newer release if somebody can
> give me good reasons. (We'll certainly switch to the latest release as soon
> as we make it to Kolab 2.1 which might take a while though.)

You should definitely upgrade because a lot of Tobias' fixes have been  
integrated since then.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/