CalDAV comments, a bit too late...
Shug Boabby <shug.boabby <at> gmail.com>
2008-09-24 13:00:54 GMT
Dear all,
I realise that CalDAV is now supported by many big vendors, including
Google and Apple, so I doubt that the protocol could be changed in any
way. Nonetheless, being called RFC-4791 implies that comments are
still welcome (and I have some steam to let off after using this
ghastly protocol which it seems we are all stuck with!)
I recently embarked on creating a J2ME application which would use a
CalDAV server to store everything. The reason is obvious, as it means
that resources are easily synchronised with all good desktop calendar
applications.
However, the first task was to learn how to make simple calls using
CalDAV and I have been astonished at how difficult and inefficient
this protocol is. It makes me wonder if any use cases were considered
during its design, and if mock scenarios were even considered. My
primary complaints are listed here, with more detail below:-
- basing it on WebDAV instead of HTTP means that most standard
libraries may not be used
- not enough can be achieved with a single query, increasing latency
for mobile devices
- using an XML query/response format is serious overkill for many use cases
- many queries and actions are too burdensome to the client, e.g.
creating new resources, timezone handling
- sharing resources with other users (even other users on the same
server) is not even considered
But in short, why is this not a simple protocol? One of the most
beautiful web APIs I have ever used is the one provided by
Freebase.com, which is trying to accomplish something infinitely more
powerful than CalDAV but does it in a protocol that is easy to
understand. It is based on MQL, but it could have easily have been
XML. Even the rich media API is incredibly simple and powerful. CalDAV
is, at the end of the day, just an online store for files that hold
all the real info, with some filters to reduce bandwidth usage and
mechanisms to allow caching... why on Earth is it so bloody verbose
and complicated!?
# WebDAV
CalDAV is based on WebDAV, which is covered with HTTP compatibility
problems. For example, all flavours of Java exclude WebDAV support in
their standard network library and use of methods such as REPORT and
PROPFIND are forbidden. Other languages face similar troubles. Support
is available from third parties on J2SE and J2EE (but no
maintenance!). No support is available for J2ME and raw socket access
is required, which is not even guaranteed on all devices, due to the
security manager.
This strikes a serious blow to mobile development, which is quite
considerable given the nature of the service that is being provided by
CalDAV! Mobile (especially J2ME) access, should have been a primary
consideration when choosing the base transport of the protocol! It
should also be noted that the current protocol excludes AJAX access to
data via the usual JSON cross-server route.
My preferred solution would have been to stick with plain old HTTP!
There is nothing in this protocol that could not have been achieved
with simple GET, POST and (optionally) PUT. I wouldn't even have
considered HTTP headers to contain anything special... something
CalDAV relies on heavily (e.g. Depth and If-None-Match).
# Too much reliance on multiple queries
It is not possible to do any of the following actions in a single
query, even if you know a user's principal URL:-
- obtain the list of all their calendars
- obtain all TODO items that have been modified since a given
timestamp or ETag was created
- create a new resource (this can be attempted in a single query if
the calendar URL is known, but it is not guaranteed to succeed)
These are all very common queries and actions. It is therefore
critical that both bandwidth and number of queries be optimised, with
preference on minimising the number of queries. On a mobile device
with a strong connection, the latency per query can be as much as 5
seconds. Without making several assumptions on the client side (e.g.
collection-home doesn't move, collections don't move), the end user
will be left waiting for 30 seconds every time they want to list their
TODO items! For example, when given a user's principal, the following
must be done in order to obtain their TODO items:-
- obtain the location of collection-home
- obtain the list of calendars
- obtain all the VTODO items, one query per calendar
which is 4 queries for the typical person with a "home" and "work"
calendar, neglecting to check for all the various methods and resource
types which are seemingly optional.
My preferred solution would have been to impose standardised URL
resource locations at the base of a server and require that all
methods and resource types are supported. For example, a user's
principal would always be at `/user/username`, with collections
`/collection/username` and possibly even some common shortcuts such as
`/todo/username`, `/event/username` which would imply that all queries
on collections should be restricted to VTODO/VEVENT items
respectively. I would also assume that queries on the collection-home
be applied to all collections/calendars! This is not the case, and
there does not appear to be a way to do it.
# XML overkill
One of the things I really like about the Freebase API is the fact
that non-standard queries can be formulated in fairly simple JSON
format (but could easily have been XML), but that for most things a
simple GET-based query will also work. It would have been highly
desirable if the most common CalDAV queries could have been achieved
as simply as sending a GET query to
server.com/caldav/todo/username/calendar?state=incomplete&from=20060712T182145Z
It might sound like this is purely aesthetic, but it is not. It takes
a lot of code to be capable of handling and creating the XML queries
that CalDAV requires, leading to the exclusion of some mobile devices.
Obviously this is just a pain to the desktop developer, but it is much
more serious in mobile development.
Also, where is the definition of the "urn:ietf:params:xml:ns:caldav"
and "DAV" namespaces? A schema is needed if correct XML is to be
expected!
My preferred solution would have been to provide some simple GET
access for the most obvious use cases, e.g. obtaining all events or
todo items, with the most common filters. To be honest, I struggle to
think of a case where a complex XML query would be required over
simple access! The XML query language is highly over-engineered as far
as I am concerned. I don't even believe an XML query language is
needed for CalDAV... it would have been enough to define an XML
response format.
# Burdensome queries and actions
I've already hinted that creating XML is often burdensome on mobile
devices, and also that creating new resources is not guaranteed to
succeed. As an example, consider creating a new VTODO item, given that
we know the collection URL. A PUT request is made to a URL that we
must create ourselves, and we must add the HTTP header "If-None-Match:
*". It is then non-obvious how one is expected to check the reason for
failure! Currently I am scanning the text of the Cosmo response for a
non-201 response and the String "If-None-Match disallows conditional
request", but this is clearly implementation specific. Creating new
resources could not have been designed to be more difficult.
Another classic example is timezone support. Prior to using CalDAV, I
had expected it to do all the grunt work of timezones... such that I
could make all my queries in GMT and never be confused. However, it
seems that CalDAV is expecting all clients (even mobile clients) to
have rich timezone support and to therefore have full international
iCal support.
My preferred solution would be to never expect clients to generate
unique URLs! Sending a POST to the base of the collections could add
the resource, and a response could indicate the server-assigned URL
and ETag, possibly even mirroring back the resource so that
server-added attributes would be known (e.g. the UID for VTODOs). I'd
also consider adding a mechanism whereby all resources are treated in
GMT and that the server does the conversions where necessary.
# No support for sharing
I am absolutely shocked at the lack of support for sharing or
delegating resources between users on a server. I can imagine that it
would be a difficult thing to do, but it would be of immense benefit
and increase the value of the CalDAV protocol by orders of magnitude.
It appears that even security issues have been considered
implementation details. Without having thought of this, I wonder why
CalDAV is so laborious. Without support for contacts, sharing and
delegation... I'm sorry to say, but I think CalDAV should really have
been quite a trivial API to design.
I've had a look at GroupDAV and I am not impressed with that effort.
Their reliance on WebDAV is again going to cause them problems, and it
has not received any traction, where CalDAV has... mostly because it
was the only protocol out there.
--
--
Shug
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
A spec is needed, though. See the WebDAV
and the CalDAV specs.
> ...
> I've already hinted that creating XML is often burdensome on mobile
> devices, and also that creating new resources is not guaranteed to
> succeed. As an example, consider creating a new VTODO item, given that
> we know the collection URL. A PUT request is made to a URL that we
> must create ourselves, and we must add the HTTP header "If-None-Match:
> *". It is then non-obvious how one is expected to check the reason for
> failure! Currently I am scanning the text of the Cosmo response for a
> non-201 response and the String "If-None-Match disallows conditional
> request", but this is clearly implementation specific. Creating new
> resources could not have been designed to be more difficult.
> ...
You should check for the right HTTP status (it should be 412).
That being said:
<
RSS Feed