[cosmo-dev] Caldav server as calendar proxy

[Brian Moseley]

On Nov 19, 2007 11:53 AM, Andre-John Mas <ajmas at sympatico.ca> wrote:

> I am currently in the process of looking at the source code
> related to the caldav server portion of Cosmo, in the hopes of
> possibly coming up with a solution that would allow wrapping of
> other calendar server APIs. The one that I would be most interested
> in interfacing with is the Google Calendar API.

that sounds like a very useful project!

> To help me move faster, can anyone tell me which is the main entry
> point for the servlet and whether there any architecture documents
> that I could be looking at?

the dav subsystem in Cosmo went through an extensive refactoring
recently, and there's no up-to-date documentation on it. that said, i
can give you a brief introduction here.

requests to /dav/* are handled by the Spring
HttpRequestHandlerServlet. this servlet delegates to an instance of
org.springframework.web.HttpRequestHandler, which in our case is
org.osaf.cosmo.dav.servlet.StandardRequestHandler. this is the true
entry point into the subsystem.

The request handler locates the targeted resource, performs
conditional method checks for the request against that resource,
chooses a provider (see below) to service the request based on the the
resource's type (calendar collection, calendar event, "regular"
collection, file, etc), and invokes a particular provider method
corresponding to the request method.

providers (instances of org.osaf.cosmo.dav.provider.DavProvider
implement the HTTP request method set for a particular resource type,
including methods defined in WebDAV and its various extensions. for a
given request method, the provider enforces method-specific
preconditions and access control, and then it reads and manipulates
the resource's state.

resources implement the org.osaf.cosmo.dav.DavResource interface, or
more precisely, either of the org.osaf.cosmo.dav.DavCollection or
org.osaf.cosmo.dav.DavContent sub-interfaces. each resource has an
associated instance of org.osaf.cosmo.dav.DavResourceLocator which
helps with building the java.net.URL and String forms of the
resource's URL and with resolving the locations of related resources.

resource implementation classes are found in the
org.osaf.cosmo.dav.impl package. there are implementation classes
corresponding to the calendar resource types (event, journal, task,
free-busy) and other resource types supported by the system. instances
of these classes are created by a
org.osaf.cosmo.dav.DavResourceFactory instance. these implementation
classes map the WebDAV data model to the Cosmo data model.

CalDAV and WebDAV access control extensions are provided in the
org.osaf.cosmo.dav.caldav and org.osaf.cosmo.dav.acl packages.

you'll notice scattered throughout the code references to code from
the org.apache.jackrabbit.webdav package. the Cosmo dav code was once
based heavily on the jcr-server library from the Jackrabbit project.
that library's API and implementation had some pretty significant
limitations that I didn't feel we could resolve within the context of
that project, so I took some of the good ideas from there and
re-implemented them in Cosmo with changes to make them more amenable
to extensions like CalDAV. there are still some jcr-server base
classes and utilities in use, but i hope to get them all removed over
time.

I imagine that you're looking for a library with a service provider
interface that you could pull into your own project and for which you
could create service providers for Google Calendar, etc. i'd like to
evolve the Cosmo dav subsystem to the point where we could pull the
core code out into such a library. i imagine that it would look
something like this:

container adapter classes:
  DavRequestHandler, DavRequest, DavResponse, DavProvider - provides
glue between the dav interfaces and the container API (Servlet, MINA,
whatever)

interfaces used by an application:
  DavProvider, DavResource and kids, DavResourceLocator, DavProperty,
DavPrivilege

implementations packaged with a service provider:
  GCalEvent, CosmoEvent, CosmoUserPrincipal, etc

when i was an active Jackrabbit committer, there seemed to be a pretty
consistent number of requests over time for such a general purpose
library. as i said before, I don't think jcr-server really fits the
bill, primarily because its main reason for existence is to serve the
needs of the JCR-using community, not the users of WebDAV. so I'd like
to be able to put some time into a project like this.

I hope this helps!