my project is a calendar sharing server that offers full-featured CalDAV access and a web-based calendaring/scheduling UI. my initial explorations have been with Slide, but i find that for several reasons i'd rather look elsewhere, not the least of which are 1) the lack of a simple content store API, which is what piqued my interest in JSR 170, and 2) the need to support a remote content store deployment. IoC-style configuration and layer separation also rank high on my list of wants, and the Acegi WebDAV project seems poised to begin working with Jackrabbit in that regard.
(1) CalDAV
CalDAV, as you may or may not know, is an extension of WebDAV that provides a content model for calendar data and defines calendar access mechanisms. my original plan had been to help contribute CalDAV support to Slide, but it may well be a much better choice to contribute that effort to Jackrabbit instead. of course, that would depend on Jackrabbit's WebDAV support being fully featured enough to support CalDAV (for instance, implementing WebDAV ACL).
for those of you who are curious, the current version of the CalDAV draft is at <http://ietf.webdav.org/caldav/draft-dusseault-caldav.txt>.
the list of CalDAV requirements includes:
o MUST support WebDAV Class 1.
o MUST support WebDAV ACL with the privileges defined in Section 7.1 of this document.
o MUST support SSL.
o MUST support strong ETags to support disconnected operations.
o MUST support all required calendaring REPORTs defined in this document.
o MUST advertise calendaring REPORTs via the DAV:supported-report-set property as defined in DeltaV.
and options include:
o SHOULD support MKCALENDAR. o MAY support WebDAV Class 2 (i.e., locking). o MAY support WebDAV DeltaV [5] or some of its components.
what would need to happen with Jackrabbit in order to pave the way for adding full CalDAV support? with such a roadmap, i may well be able to convince my employer (OSAF) to throw some support behind this effort.
(2) remote content store/scalability thoughts
i'm also curious what alternative methods you've implemented and/or envisioned for remote content store access. i saw mention in the list archives of RMI, though at least one person expressed a worry at the performance of such. have any other mechanisms been proposed, or is WebDAV the one that people like the most?
has any thought been given to clustering/replicating/distributing/otherwise horizontally scaling content stores? i could easily build a massively hosted web calendar UI using traditional clustering techniques and my own custom content store API on top of an RDBMS, but i'd like to leverage JCR as much as possible.
there is of course a school of thought that many small content stores with a locator service like DNS that identifies the individual store holding a specific piece of content is a more scalable architecture than one uber content store. presumably today's Jackrabbit design would suffice for this architecture, assuming such a locator service was provided. am i correct in this assumption?
