[Kolab-devel] Is IMAP still the right choice?
Georg C. F. Greve
greve at kolabsys.com
Wed Nov 30 12:13:22 CET 2011
On Wednesday 30 November 2011 11.19:33 Thomas Koch wrote:
> - for the disadvantages listed, most importantly the complexity of IMAP
> which may be a burden for people to write clients for Kolab
Virtually all Kolab clients *must* support IMAP for email anyhow, as virtually
all groupware clients support email and despite the claims that email is dead,
I don't see it decrease in importance in the professional world.
> - Using IMAP means in practice that there is no place for an intermediary
> server component to either check written data for validity or to hide
> changes in the storage format from the clients.
...and thus no mandatory server-side performance penalty for this, or the
various aspects of handling incorrect aspects of data, including data that was
created or modified offline.
The protocol to handle all of that to the same level that Kolab provides today
will become quite complex, I dare predict.
> All clients have direct read/write access to "plain files". This in turn
> makes it hard to evolve the storage format.
Most clients don't do that, they use the Akonadi or Horde based APIs for
access Kolab objects. They are not as good as we'd like them to be, so we're
thinking about where this should go as you can tell from the mails that have
been sent to kolab-format@ and kolab-devel@ over the past weeks.
Most likely there will be a format library that wraps the actual format with
language bindings for most languages, so clients have a client side API to
work with that ensures object consistency, putting the burden of that
operation onto the client, which is where it can scale.
> - There may be additional disadvantages of IMAP compared to HTTP which I'm
> not aware of since I don't know IMAP internals. Therefor I'm asking.
The obvious ones would be full offline capability and being robust against
interruptions & re/-sync. In any case I suppose you would not want to come up
with your own HTTP based email protocol for your server?
> IMAP is not the storage backend but the communication protocol between
> server and clients. The storage backend is the mailbox format of cyrus. Is
> it maildir?
Various IMAP servers use various backends for storage, e.g. Cyrus IMAP has a
large amount of options, including scaling up to TB of data and hundreds of
thousands of users, with data migrating between faster/slower disks and so on
and so forth.
Jeroen could explain a lot about this for several hours, I am sure.
What most people don't realize is that IMAP ultimately is a NoSQL database.
Kolab has understood this very early on and was ultimately pioneering the
concept of NoSQL with using IMAP as the database to some extent. Since IMAP is
optimized for the most resource intensive operations a groupware server has to
deal with, our experience is that this works rather well. In fact it works so
well that people are working on a CalDav server as part of Cyrus.
Exchanging it against another NoSQL database that is not optimized in this way
for benefits that are hard to asses is not particularly attractive, to be
And yes, as Gunnar pointed out correctly, this has nothing to do with REST.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the devel