[Kolab-devel] Can Horde be fixed?

Fri Aug 18 16:42:59 CEST 2006

Hi,

Just installed and configured the Horde webclient on a separate machine. 

Calendars seem to integrate very well (didn't check for recurrence and stuff
only simple things). However due to the lack of caching the loading takes a
while. For example : a calendar with 517 items takes a little less then 1
minute to load. This isn't workable, only for simple one-time viewing. I
don't think the IMAP connection to the separate IMAP server will have that
much impact.

So in my opinion caching is absolutely needed.

I'm also wondering what happens when you're using your calendar for a number
of years. Are the old items automatically removed somewhere? Or is it just a
growing mailbox? In the later case loading a calendar with the webmail
client will be very slow.

Kind regards,
Pieter

-----Original Message-----
From: kolab-devel-bounces at kolab.org [mailto:kolab-devel-bounces at kolab.org]
On Behalf Of Gunnar Wrobel
Sent: dinsdag 8 augustus 2006 18:44
To: Kolab development coordination
Subject: Re: [Kolab-devel] Can Horde be fixed?

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel

--
---------------------------------------------------
Able: 1996-2006: already 10 safe years in YOUR company!

aXs GUARD has completed security and anti-virus checks on this e-mail (http://www.axsguard.com)
---------------------------------------------------
Able NV: ond.nr 0457.938.087
RPR Mechelen