jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <daniel.flo...@web.de>
Subject AW: webdav server(s)
Date Thu, 15 Dec 2005 12:18:01 GMT
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: jackrabbit-dev-return-4903-daniel.florey=web.de@incubator.apache.org
> [mailto:jackrabbit-dev-return-4903-
> daniel.florey=web.de@incubator.apache.org] 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



Mime
View raw message