hi brian, > what is Jackrabbit's strategy for WebDAV support?
we are currently working on a WebDAV based jcr client/server protocol. It uses the standard webdav protocol elements with a few extensions and some extended semantics on locks. we also integrated microsofts observation model (subscribe/poll). the idea is to have a jsr170-to-jsr170 WebDAV layer that is not strictly tied to jackrabbit. The jackrabbit dependant part of the server is minimal. we recently contributed the server part of it while still working on the client. you can find it here: http://svn.apache.org/repos/asf/incubator/jackrabbit/trunk/contrib/jcr-server you can find a documentation draft of the protocol here: http://www.day.com/jsr170/server/JCR_Webdav_Protocol.zip > are you > providing a stripped-down implementation specifically as a > mechanism for remote access between JCR clients and a > Jackrabbit content store, or do you intend to build a > full-featured WebDAV adapter on top of a content store, or > both (or neither)? both. along with the JCRWebdavServer part comes a very simple WebDAV servlet, that exposes the repository in a file-system like way. meaning, nt:file is mapped to a non-collection-resource, everything else mapped to a collection. most of the webdav operations should work. the JCRWebdavServer will also support DeltaV methods for versioning. > [...] > 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. i suggest you take a look at the stuff that is already contributed. you are probably the better person to judge what else is needed. further you need probably decide, if the calendar data is stored in a unstructured way, defined by the cal application, or if CalDAV needs a predefined nodetype set for this. > (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. no, currently only RMI is implemented and working. > any other mechanisms been proposed, or is WebDAV the one > that people like the most? afaik, webdav and RMI was the only remoting protocols that were really wanted. > 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. not yet. please keep in mind, that jackrabbit is a reference implementation. the primary goal is to make it working according to the spec. > 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? yes. if you know what content you need. with a distributed jcr repository it is harder to leverage it cool features like integrated search and observation. cheers, tobi -- ------------------------------------------< [EMAIL PROTECTED] >--- Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
