On 17/02/2012 4:53 a.m., Cyrus Daboo wrote:
Hi Adrien,
--On February 17, 2012 12:44:56 AM +1300 Adrien de Croy
<[email protected]> 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.
I'm not discounting the difficulty and complexity of writing
calendaring. It's just that putting it over HTTP adds complexity is
all. Not everyone can use an off-the-shelf component for that.
Writing a web server is non-trivial. Making it hardened enough to
withstand the internet is another issue.
It's harder to defend against http-borne attacks than IMAP attacks.
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.
Yeah, I don't know that I was proposing building CalDAV into IMAP
itself. That's where I was going with layering.
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).
IMAP is fairly feature-rich. E.g. If we want to support server-side
searching (which I hope we do), then the server needs to be able to
unpick mime, and have a query language rich enough to be useful. That
seems to me (on the face of it) to be a bit beyond just a mail store.
Regards
Adrien
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
