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

[Ian Reinhart Geiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 July 2003 11:03 am, Andrew Kohlsmith wrote:
> > While this is a repackage of an older project, I have yet to see it work.
> > There is a ton of hype behind it but IMHO they have a few disadvantages.
> > The big one being the huge database backend.  By using IMAP to store
> > information and LDAP to store the config and accounts I think kolab has
> > more flexability.   Now advantages we can catch up with quickly.  The
> > webdav support is pretty easy with a nano (i think this is the webdav
> > python server) and they pyimap code.  Someone with time and energy could
> > duplicate this quickly.   Im not sold on the webdav part though over a
> > native MAPI transport and datastore like im doing.  The only real
> > advantage for the Gnomes is evolution can use it out fo the box.
>
> I am currently evaluating Exchange4Linux (exchange4linux.org) -- It uses
> one big badass database for everything as well.  I've been dumping tons of
> data into it to try and test it in terms of speed and compatibility with
> Outlook.
>
> I hate to say it, but that really is my #1 priority at this time: Outlook
> compliance.  Until I can get a decent cross-platform groupware client, my
> office is stuck with it.  Exchange4Linux has one very big advantage that no
> other project to date has achieved: 100% Outlook functionality.
>
This is why we went the route of a mapi datastore, transport and addressbook. 
We talk directly to imap and integrate solidly with outlook. 

> E4L stores _everything_ in a postgres database, including email.  Any
> attachments are stored as large objects.  The server software is all Python
> and communicates with the proprietary Outlook connector via CORBA.  (i.e.
> the Outlook connector is a MAPI <--> CORBA gateway.)
Speedwise, we are doing pretty good.  Our test server is a P2 Celleron at 
400Mhz and has 256Mb ram.  Our client is a 800Mhz athlon.  Raw email speed we 
can dump about 40Mb of mail from the client to the server in about 15seconds.  
This includes our time to construct a message, send it over 100Mb and the 
server creates it.  We are about 10seconds to read the messages.  Now granted 
outlook will give us some overhead, but imap server like cyrus and currior 
are friggen fast.  I could probibly go out on a limb and say faster than 
postgres at dishing up blobs of data.  

>
> Speed so far has been crappy, but I am working on tuning pgsql for better
> speed, which I think is a large part of the problem, although moving the db
> to a fast SCSI storage system and throwing a ton of processor (P4/2.2G) at
> it has causes the new bottleneck to appear to be the Python server itself.
>

Currently our speed issues are with outlook.  Their API is convoluted and 
contradicts itself all over the place.  Luckly we have our imap library done, 
and it can read/write and send email.  Our current sticking point is getting 
Outlook to reliably keep track of our Mapi property tables :P

I personally think the advantage KOLAB will have over these other approaches 
with a database is that imap can server files FAST.  I mean thats what an 
email server is built to do.  Databases where never ment for large blobs of 
data like email and vcal events.

Cheers
	-ian reinhart geiser
- -- 
- --:Ian Reinhart Geiser <geiseri at yahoo.com>
- --:Public Key: http://geiseri.myip.org/~geiseri/publickey.asc
- --:Public Calender: http://geiseri.myip.org/~geiseri/publicevents.ics
- --:Jabber: geiseri at geiseri.myip.org
- --:Be an optimist -- at least until they start moving animals in 
- --:   pairs to Cape Canaveral. ~ Source Unknown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/DYNyPy62TRm8dvgRAlegAKDOn1qz7bLg8vmXFE5Nj0rgnn+QywCfV6Ki
0SAYRtXMC+tOr/SUFkwHeCA=
=nuQ0
-----END PGP SIGNATURE-----