[Kroupware] OpenGroupware.org formed through SKYRiX open sourcing its Groupware server

Andrew Kohlsmith akohlsmith-kolab at benshaw.com
Sat Jul 12 20:46:49 CEST 2003


> AFAIK the problem with E4L is, that they store *every* MAPI attribute
> as a single SQL row which obviously doesn't scale.

I'm not sure what you mean here -- There are basically two tables; object 
and properties.  If you wanted to pull all the properties for an object you 
do the appropriate select on the property table.  

Seems like it'd scale _wonderfully_ well.

> > E4L stores _everything_ in a postgres database, including email.

> Which is a very bad idea. SQL database are for storing multiuser items,
> not for email - the transaction and integrity overhead for an almost
> exclusively user centric store like email is certainly too high.

I've been playing with it some more, and the performance issue is more to do 
with the current Python server than anything else; they are doing sorting 
and whatnot in the Python server instead of in the DB, and have stated why 
and that it'll be done correctly in the new version, scheduled to be 
released at the end of the month.

While you're correct that there is extra overhead, I don't think that it is 
going to be very significant.  Time will tell.

> The problem is that the E4L connector does not "understand" the MAPI
> messages. It just splits them up into separate rows and stores them as
> raw attributes. Since a MAPI message has about 50-100 individual
> attributes you end up with 50-100 times the rows actually required (in
> other words, with a MAPI plugin which properly handles MAPI messages
> you can serve about 50 times more users on the same hardware
> [oversimplified]).

Yes, this is exactly what it appears that E4L is doing.  Personally I think 
this is a _good_ thing, because the MAPI connector is nothing more than a 
bridge, and all the work is done in an open server.  I am keeping my eyes 
on Kolab though, I would like to do some comparisons once the MAPI client's 
released.  I'm _really_ hoping that Kolab releases a "tester" chroot 
environment much like E4L to make testing very easy. :-)

Regards,
Andrew


More information about the Kroupware mailing list