Re: [imap5] Designing a new replacement protocol for IMAP

[Cyrus Daboo <[e-mail]>]

Hi Adrien,

--On February 17, 2012 12:44:56 AM +1300 Adrien de Croy <[e-mail]> 
wrote:

>> The Cyrus Project aims to include CalDAV support as part of the Cyrus
>> IMAP server, which would make CalDAV deployment much simpler for any
>> sites that are already running Cyrus.
>
> as someone looking to add CalDAV to a mail server, wouldn't it be nice if
> you didn't have to
>
> a) write a web server
> b) write DAV extensions
> c) layer XML on top of that
> d) debug / support all of the above
>
> just to get a calendar?

You fail to appreciate the hard part here - it is not the protocol (which, 
guess what, is not that hard to do as there are many off-the-shelf webdav 
implementations to pick on as a starting point - and indeed within a few 
months of the initial draft being published we had several servers and 
clients interoperating). The hard part is the semantics of calendaring. As 
someone who has lived in both the IMAP (email) world, and the 
iCalendar/CalDAV world, I can tell you that calendaring is like an order of 
magnitude more complex than email - specifically scheduling.

CalDAV servers are very "write heavy" in that there are a lot of 
modifications happening to existing data - that is something not typical of 
an IMAP server where modifications are simply metadata changes (flags) or 
actual message "injection" (delivery, APPEND) or deletion. So if you want 
to build a high performance CalDAV server you need to take that into 
account and build something whose scalability is based on a different set 
of client/server interactions than is typical for IMAP.

That is not to say that building that within IMAP or on top of an existing 
mailstore is impossible - it is. But what is more important is to fully 
understand the core use cases - or more importantly the requirements for 
the client/server api.

What I would really like us to focus on here, is not IMAP5 per se, but 
instead a "generic" mail store access API. Lets define the key operations 
needed by clients and a server API that can provide those behaviors. Once 
we have that, we can fit it into any protocol we like, be it extensions to 
IMAP4 (to make IMAP5), HTTP, XMPP whatever. The same thing can be done for 
a calendar store api (and indeed the Calendaring and Scheduling Consortium 
has been working on generic abstractions giving rise to REST and SOAP based 
protocols all built on the same store api model used by CalDAV).

-- 
Cyrus Daboo