Kolab2 architecture/format flaws

[Zachariah Mully]

On Sun, 2005-05-15 at 10:24 +0200, Martin Konold wrote:
> You are still trying to "abuse" the IMAP store like a relational database. 

That's because the datastore probably should have been a relational
database in the first place instead of an IMAP store (which I still
don't understand).  Instead, functionality has to be duplicated all over
the place...

> > I know Cyrus IMAPd is supposed to be able to index/cache headers so maybe
> > this small change could make a big difference?
> 
> This could help/hide the problem partially while putting load on the server 
> and the problem will reappear latter.
> 
> BTW I don't understand we you don't like the proposed solution. Can you please 
> explain why it is so difficult?

Speaking for myself, I don't like it when I have to duplicate
functionality in two different places, in two different languages
because of an odd mime-type requirement. I spent some time testing Cyrus
search capabilities on Friday and I was pretty impressed with them. On
an unindexed calendar store, where I had manually set all kolab mime
types to text/x-vnd.kolab.event, with 7600 distinct objects, finding a
unique message using SEARCH BODY took 0.730 seconds.  On the same
calendar store, indexed with squatter, it took 0.070 seconds. And this
is on a craptacular machine, that is nowhere near as fast as what some
of you are running out in production. 

I don't think it's unreasonable to allow for this type of searching to
be done. It might not handle a super large webclient only installation,
but for the majority of installations, I bet you'd never notice the
difference. It's simple and robust to implement, instead of having to
write a db cache driver and syncronization code for the webclient, you'd
simply be able to request the required data from the server.

Z