[Kolab-devel] Can Horde be fixed?

[Gunnar Wrobel]

Bernhard Reiter <bernhard at intevation.de> writes:

>> > As I already mentioned I believe that the whole manager login problems
>> > and the datatree issues can be solved and the code I wrote last week
>> > works reasonably well so that I'll be able to send it upstream for
>> > review soon. So that basically leaves the caching problem as also
>> > summarized on http://wiki.kolab.org/index.php/Horde
>
> The caching problem might be critical.
> On the other hand, it would be great to have a webclient.

Yes, it is certainly is an important point for large
installations. But its good to know that it might be the only point
left in making horde an acceptable client even for larger
installations.

>
>> > Under the assumption that any new web client would also be written in
>> > PHP 
>
> When a project for a new webclient is made, the choice of language would be 
> open. Personally I would prefer Python.

Would be my personal preference, too :) And actually a very strong
preference.

> In addition look and feel and asynchronous operation could be brought into the 
> picture as well. Ideally I would want to have client libraries that can
> be used by several clients and not just the webclient itself.
> But this is dreaming, so far. ;)

Yup, would be very nice indeed.

> Next is the business logic, we have put quite some time in getting the 
> iCalendar invitations working nicely enough with existing clients like 
> Outlook. We expect that Horde will have some bugs in that area as well.
> Doing the quality control and fixing the bugs would be almost as much work
> as doing it on a newer client.

Taking into account that Kolab currently uses the iCalender libraries
from Horde in the resmgr scripts I doubt that work on that specific
Horde library can be avoided.

>> > I don't understand why there would be any reason to implement a 
>> > new web client. Anything coded in PHP would probably use the PEAR
>> > Net_Imap package for accessing the server anyhow. And I don't think it
>> > is unreasonable to assume that the major part of the cache would
>> > actually be just a wrapper around this PEAR package. So the code of
>> > the client itself would probably be minimally affected by the decision
>> > to use a cached connection or not.
>
> Conflicts need to be handled which needs some integration.

Yes, I am certain there would be more parts of the code affected than
I anticipate now. But on the other hand I do believe that a major
portion of the caching benefit could already be achieved by coding a
rather simple Net_Imap wrapper.

>
>> I completely agree with that and i think that when the problem of :
>>
>> - manager logins
>> - datatree issues
>>
>> is corrected the horde client will be a goo enough solution for small
>> groupware.
>
> For how many people will this work?
> If Gunnar has a well working version, can anybody do a stress tests?
> I am really interested, because of course, part of the discussion
> could not be feeded with good test data.

The Gentoo users should run with my horde patches but I have no clue
how large their installations are. Mine are all rather small.

Maybe Fabio can report back since he suggested he might switch over to
the Gentoo version - which I encouraged of course :)

For anybody that wants to take a look if Horde is completely broken
with the patches or not: You can play around with our demo server at
http://demo2.pardus.de. You can log in with wrobel at demo2.pardus.de and
pass 'test'. No guarantees that this thing is always online though, we
are still playing with the machine.

>
>> I still think that the horde system is the best solution for the whole
>> groupware
>
> People report that Zimbra and Zarafa look slick and fast
> and Horde looks a bit oldfashioned.
> I have not seen all enough of all three to actually have an opinion,
> but if those people were rights, there would be more work again.

Did you take a look at DIMP? This is the new AJAX powered webclient of
horde and also another reason why I think that horde is a good
choice. Horde is a rather large project with a lot of development
energy behind it. Taking such a thing and tweaking it to your own
needs seems more reasonable to me than starting from scratch. Having a
nice and shiny GUI with all the dynamic stuff that users are starting
to get used to is not an adhoc task.

Thanks for your feedback Bernhard!

Cheers

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : wrobel at pardus.de                          Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                      Hartwig-Hesse Str. 12
Fax    : +49 40 432 70855                            D-20257 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >> Mail at ease - Kolab out of the box <<                 P at rdus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~