[Kolab-devel] Is IMAP still the right choice?

[Georg C. F. Greve]

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

And yes, as Gunnar pointed out correctly, this has nothing to do with REST.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20111130/4a9acbb8/attachment.sig>