[email protected] schrieb am 08.03.05 20:09:54: > > 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).
Have you seen the Slide implementation (Client & Server side) for this? It can be extracted from the Slide project easily. The Client part (NotificationListener) handles udp & tcp based notifications and works fine with MS exchange. If you need some help just let me know. Daniel 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 >--- __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201
