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

[Andrew Kohlsmith]

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

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

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.

The _really_nice_thing_ about E4L is that all my outlook data is in 
English...  the basic concept is objects and properties.  There are two 
basic tables for each user: an object and property table, and then a pair 
of tables for public objects and properties.  Each contact, email, calendar 
entry, journal entry, etc. has one object entry in the appropriate object 
table (user or public), and then all properties for that object appear in 
the relevant properties table.  On average, each contact has about one 
hundred properties associated with it.  Each property has a 
human-understandable name and the data is also easy to understand for the 
most part.  There are some "gobbledegook" properties that I assume are 
Outlook-internal.

In order to present data to non-outlook clients, more software needs to be 
written for E4L.  There is a (rudimentary) IMAP4 server, but an LDAP and 
ICAL/MCAL server will be necessary.

I realize this is offtopic, but after looking at the way that E4L handles 
this data, I am starting to believe that the ideal way to handle the vast 
majority of the data is in a database, perhaps with various front-ends 
(IMAP4, LDAP, ISchedule)...  I was a believer in the "IMAP server, LDAP 
server, etc. with some DB to tie it together" until I started playing with 
E4L...  now I'm not so sure.  They're two different ways of doing it, but I 
think that both methods have _significant_ merit.  I suppose it comes down 
to how badly email performance is impacted.

Regards,
Andrew