On 12/15/05, Daniel Florey <[EMAIL PROTECTED]> wrote: > 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
just wondering what the benefit would be of promoting a dead project to TLP... cheers stefan > 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 > > >
