[Kolab-devel] Can Horde be fixed?

[Bernhard Reiter]

Am Sonntag, 6. August 2006 22:35 schrieb Benoit Mortier:
> Le Dimanche 6 Août 2006 21:40, Gunnar Wrobel a écrit :
> > Martin Konold <martin.konold at erfrakon.de> writes:
> > >> At least the groupware object emails MUST be
> > >> cached, otherwise you will need to completely search, retrieve and
> > >> parse the relevant folders if you want to just re-display.
> > >
> > > This is very much correct. E.g. in order to be able to make use of the
> > > calendar a Kolab clients needs access to all object at once. (Think
> > > about recurrances etc.)
> >
> > I think nobody disagrees that imap caching would be a desireable thing
> > for the horde web client. In fact actually any web client that works
> > with the kolab server.
> >
> > The impression I got from the discussions so far was that writing a
> > new web client might be easier than getting horde to work efficiently
> > together with the kolab server.
> >
> > I completely disagree with that notion.
>
> Mee to ..

I depends on the requirement you have for the webclient.
If a webclient without a cache for the groupware objects
uses a hundred times more requests then a regular Kolab client,
it will only work in environments with a small number of users and 
sufficient cpu power.

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

> > 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.
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. ;)

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.

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

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

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

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060808/d1150189/attachment.p7s>