Hi folks, this in an interesting thread. It would be great to have a full featured WebDAV-stack implemented in Java with a simple and consistent api. When the Jackrabbit project started, I was little bit frustrated that people started to reinvent the wheel instead of using simple WebDAV-to-java-method-mapping as api. So I stuck with the Slide project even though the codebase is really a mess and nobody really likes to work on it. If there would be a combined effort to implement a robust WebDAV-stack, I'd really appreciate this. Let me summarize the goals of such a project from my point of view: 1. The big advantage of WebDAV is that users can (in theory) use existing clients to communicate with the server. There are many clients supporting the very basic WebDAV set, but not many using any advanced WebDAV-features (Delta-V, DASL, ACL). The best WebDAV-clients supporting Versioning (and this seems to be the hardest part to implement) are subclipse and TortoiseSVN. So my primary goal of an apache WebDAV-project would be to be interoperable with subversion. This could also include close communication with the subversion team and perhaps changes to make subversion more WebDAV-compliant and discussions on the DeltaV-mailing list to incorporate extensions that subversion introduced into the spec if necessary. It could be part of the WebDAV-project to provide new features for the subclipse-Plugin to support ACL, DASL, Bindings and other WebDAV-features right out of eclipse. This could lead to a RCP-solution to provide a robust and mature cross-platform WebDAF-client. 2. Support of all important specs that you can find on Julian Reschke's great webdav site: http://www.greenbytes.com/tech/webdav 3. The server implementation should be open to make it possible to add support specs easily. This requires a good concept of virtual resources and live/dead properties. But theses details can be discussed later on. 4. Provide a single api for both local and remote repository communication. In case of remote repository communication of course WebDAV should be used as a protocol to enable communication with existing WebDAV-servers (Ms Exchange, SAP Netweaver, Software AG's Tamino-Server etc). 5. Support for feature examination. The api should reflect the different levels of WebDAV support that the server provides. ACL's can be exposed in different ways, some specs may not be supported by certain servers. This should be reflected in the api.
We are currently discussing to move Slide to TLP at the Slide-dev-Mailinglist. Personally I'd prefer to create a new webdav.apache.org TLP and start something more elegant from scratch. If there is a chance to combine the efforts taken in the Slide and in the Jackrabbit project concerning the WebDAV support, I'd be glad to support this effort. Cheers, Daniel > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:jackrabbit-dev-return-4903- > [EMAIL PROTECTED] Im Auftrag von Robert r. > Sanders > Gesendet: Mittwoch, 14. Dezember 2005 20:27 > An: jackrabbit-dev@incubator.apache.org > Betreff: Re: webdav server(s) > > As someone who has been monitoring both Jackrabbit and Slide lists this > idea struck me before. If the people still working on Slide could be > brought over to work with some of the Jackrabbit people it seems to me > that this would be in the best interests of both communities. I don't > know how this would be done, or wether a TLP or a subproject would be a > better alternative. While they aren't the same (and I am not an expert > on either) it seems obvious that there are some gains to be made by > having a full featured WebDAV server with a JCR backend. > > Stéphane Croisier wrote: > > > > There is a thread running on right now on the Slide Dev List about > > moving Slide to a Top Level Apache Project (TLP). Currently we are > > using Slide as a temporary solution to store some binary files for our > > CMS and I agree quite a lot with the conclusions of Brian... The Slide > > project is nearly dead and without nearly any activities from > > beginning of this year. > > > > So the best solution would certainly be to open a new "dav.apache.org" > > top level project which would include a Slide 3.0 full refactoring > > based on Jackrabbit (or whatever would be the new name of such a > > project) and try to gather all the currently scarce DAV ressources and > > expertises into one single project.... Then CalDAV or other DAV > > extensions would then also easily fit in such a new TLP... > > > > My 2 cts... > > Stéphane > > > > At 17:31 14.12.2005, Brian Moseley wrote: > >> Stefano Mazzocchi wrote: > >> > >>>> personally, i have no interest in working on such a thing. i > >>>> wouldn't tell somebody not to do it, but i wouldn't help them either. > >>> Can you tell us why? > >> > >> i found the slide codebase to be extremely confusing, verging on > >> incomprehensible. i was unable to make heads or tails of the apis and > >> had only the vaguest inkling of how i might extend it for caldav. > >> > >> by contrast, the jcr-server design is relatively simple and elegant, > >> and the extension points are natural and obvious. > >> > >> also the slide community didn't seem to have much momentum back in > >> the spring of 2005. there was no defined release plan and extremely > >> little support on the mailing list. the documentation that existed > >> was sparse and often frustratingly unintelligible, so when you had > >> questions, you were basically screwed. > >> > >> things might have changed for the better with slide, but i'm not > >> optimistic. i vastly prefer the jackrabbit code and community. > > > > - -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- - > > www.jahia.org : The Java Unified Web Platform > > > > -- > Robert r. Sanders > Chief Technologist > iPOV > (334) 821-5412 > www.ipov.net
