I think that core is the right audience to bring this up.
As I was starting to work on a rails plugin to complement my ri_cal
gem, I thought that a simple CalDav server might make a neat source
But that got me thinking about how CalDav fits into Rails in its
current and future state.
WebDav can be thought of as an extended http which adds a handful of
new methods for manipulating resources and collections of resources.
CalDav further extends WebDav with two calendar specific methods for
creating and querying calendar resources.
I don't want to get into a religious discussion about whether or not
CalDav/WebDav is RESTful. FWIW Roy Fielding seems to think that
although the extensions aren't really necessary, WebDav (and
presumably CalDav) are more OK than some of the other things out there
on the interwebs.
Now in googling about, I discover that there's a railsdav plugin whose
usage I don't entirely understand.
One thing it does is to patch ActionController::AbstractRequest (or
ActionController::Request in Rails 2.3) to add the webdav methods to
the HTTP_METHODS constant. It's not clear whether this is enough to
allow routes to use the new methods as condititions or not.
It seems to me that this kind of patch is right where things are being
changed for Rails 3.
Would it be worthwhile to consider having an explicit extension API in
rails 3 to add 'http' methods in such a way that both dispatching and
routing takes the new methods into account?
I also notice that there is a rackdav project which provides a rack
middleware which understands webdav protocol. This appears to be
written as an 'endpoint' middle ware, it doesnt seem to provide for
passing through. This gave me that idea that another alternative to
adding methods to rails might be to interpose a rack middleware which
converted requests with webdav/caldav methods to requests with normal
http methods, by either rewriting the uri in some defined fashion
and/or adding parameters.
But that seems less compatible with the Rails approach, I think I'd
like to be able to route requests to different controllers/actions the
same way I can do with normal http rest schemes.