Kolab2 architecture/format flaws

[Andreas Gungl]

Am Donnerstag, 12. Mai 2005 23:59 schrieb Zachariah Mully:
> I guess I am a bit mystified why the designers chose to store everything
> in an IMAP backend (which is fine), BUT then defined the Kolab objects
> in such a way that there is no way (to my knowledge) optimize the
> retrieval of objects from the backend. It's like using a database
> backend but then storing all the data you need to select against in a
> binary format that the database doesn't understand!
>
> This really has the most impact on the webclient since there isn't an
> good way to cache the messages, but it also means that any fat clients
> are going to have do a lot of fetching and pre-processing of messages
> before getting any usable information from them.
>
> If the developers expose the contents of the Kolab objects to Cyrus,
> then Cyrus' built-in indexing and caching can be used fully. Maybe I'm
> blowing this out of proportion, but I think it has the potential to
> cause serious performance issues and should be addressed.

Hi,

I can see the slowdown as well and I'm a bit worried about the time needed 
to present 180+ (mostly recurring) events in Horde. We're running a Dual 
2.8 GHz Xeon machine and although I didn't bother optimizing anything (or 
even installing a PHP accelerator) so far, I don't believe it to be easy to 
handle 500+ events in an appropriate time.
OTOH, the fat clients which are the primary concept in Kolab can handle the 
data pretty well. If you're running Kontact, you're on the safe side.

Anyway, Kolab support in Horde is still in an early stage. Given the current 
speed of improvements I better don't bet on it any longer. I think, 
alternatives like SyncKolab + TBird will help to limit the need of a web 
frontend but well, a remote HTTP(S) access needs a web solution...

Regards,
Andreas