A (currently theoretical) question concerning a book about the Kolab Server

[Gunnar Wrobel]

Hi Richard,

I'm responding to the first part of your private e-mail in
public. Hope that is okay ;)

Richard Bos <richard at radoeka.nl> writes:

> Hello Gunnar,
>
> Op donderdag 10 juli 2008 13:33, schreef Gunnar Wrobel:
>> While I like Gentoo my main area of activity is the Kolab groupware
>> and I'd be really interested in writing a handbook for administrators
>> of the Kolab server.
>
> if you have time: can you give an explanation what the big difference is 
> between kolab and other solutions like: scalix, open-exchange, zimfra (I 
> think it is called).
>
> From my perspective, kolab is fully open source, each and every component is 
> open source.  That's one thing.

This difference is also what makes it easier to do the native
ports. Not that native ports are easy but when I chose Kolab three
years ago it was obvious that neither scalix, open-exchange, nor
zimbra would be open enough to get easily ported to Gentoo.

> The other thing is that kolab is fully based on a directory (ldap)
> and imap storage instead of a database.  But what is the big
> advantage of using a directory and imap storage instead of database?
> With IP everywhere a database is also very reachable from each
> location, even from remote locations and databases can be replicated
> as well.

You only look at the administrators point of view here. Of course the
server admin can access a database. But what about the user? This is
the most crucial point about Kolab for me. Of course Kolab offers a
lot more than IMAP based storage of data. But to me this is the core
element. And it is not a technical reason why I'm excited about this
but a plain social one.

Storing data in IMAP means the user has full control of his
data. Assuming there are several Kolab providers you could simply move
all your data from one provider to the next. It would not even be
necessary that these are Kolab providers. Just IMAP providers would be
enough (see my latest message on Kolab on Gmail).

Putting the user in control of his own data is crucial to me if I look
at the current growth of web 2.0 applications. We happily store all
our data in the databases of a large number of different companies. We
don't remain in control of that data and we usually can only access it
via an API provided by the company.

I'm not overly paranaiod about this but conceptionally I believe "full
control of your data" will be a very important concept in the
future. And relying on IMAP for data storage gives you exactly
that. User are already now in full control of their e-mail. If they
change the provider they have the possibility to migrate their data
with them. So with Kolab nothing changes for them.

On top of that it would actually be easy to encrypt the Kolab data
stored in IMAP. So your IMAP provider wouldn't even have access to the
private data you store on the servers.

>From a technical point of view it is of course easier to use a
database. That's the primary reason why that is the standard concept
in web applications.

But look at the progress Horde made in recent years: The caching is
starting to be pretty good and I think there will be no major
difference in speed when compared to the database driven Horde
installations after another round of speed optimizations. The initial
hurdle might be higher when using IMAP but once you get that right the
user experience should be the same.

The Horde libraries I'm going to push out soon should also reduce that
initial burden. You will be able to take these PEAR libraries and rig
your favourite web application for Kolab storage without too much
hassle. At least if that web application is structured well enough.

Cheers,

Gunnar

-- 
Gunnar Wrobel
__________________C_o_n_t_a_c_t__________________
Mail: wrobel at pardus.de
WWW:  http://www.gunnarwrobel.de
IRC:  #gentoo-web at freenode.org
-------------------------------------------------