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

[Andrew Kohlsmith]

> This is why we went the route of a mapi datastore, transport and
> addressbook. We talk directly to imap and integrate solidly with outlook.

Ok...  Is there documentation on how to take the 4000 Outlook contacts that 
I have in a public folder and get them on to the Kolab server?  Or existing 
email, schedule data, etc.?  That is the one sticking point I always had.  
In E4L I exported to PST and imported into the E4L message store.  Would 
the procedure be the same?

Another sticking point is offline mode -- is there any way to do this in 
Kolab?  I'm not trying to pick a fight; E4L doesn't do this and I am 
curious if Kolab does. 

To be honest, Kolab's on my list of packages to evaluate.  I have given up 
on SLOX; they said they had to contact their legal team with respect to my 
signing an NDA in order to get documentation on the APIs and so forth but 
that was over 6 weeks ago.  Oh well.  E4L just jumped at me the other day 
and their chroot eval download was dead simple, which is why it was 
evaluated before Kolab.  :-)  

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

Yeah the mail import speed was fast on E4L as well but contacts take 
_FOREVER_ (on the order of 4 hours for 4000 contacts) -- each contact has 
about 100 properties and that seems to be where the trouble was, perhaps in 
the CORBA transaction.  I was diskbound before but I should import it again 
and see what it takes this time around on a fast UW2 disk system.

I haven't really benchmarked pgsql with large object speed, but I imagine 
you are right; pgsql is designed to be a database, not a file server.

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

Exactly.  That's why I was wondering why E4L uses pgsql to store email as 
well, instead of spitting it over to a Maildir and letting a standard IMAP4 
server handle it.  I have only been evaluating it for about 4 days now so 
there may be some good reasons from their perspective.  :-)

Regards,
Andrew