> > But I think that the WebDAV for Jersey should not use the JCR. It
> should
> > implement the WebDAV-Methods and Features and should not point to a
> > special api. I want to use this WebDAV feature for a lot of things.
> And
> > there is still a WebDAV implementation for the JCR. So why should
> this
> > project use JCR? I also know the talks about the CMIS and this is not
> > the list for it. :)
> > ...
> Well, implementing WebDAV in a server requires implementing the
> protocol
> itself (that's where JAX-RS helps), and interfacing to some kind of
> storage.
It is not essentially needed to interface to a physical storage (but it
makes sense in 99.9% of all use cases): You could e. g. use my WebDAV
contribution to have a WebDAV frontend but completely implement the
processing inside of your JAX-RS resource (like checking temperature sensors
or list them up as a result to a PROPFIND call; or list the IDs and
positions of all GPS transmitters built into the car pool of your company).
Not everybody has the demand to wrap a CMS/DMS, so my initial contribution
targets in the frontend, while JCR or an SPI targets more in the backend.
This is why I'd like to split efforts in these two distinct sections.
Regards
Markus