hi julian Julian Reschke wrote:
From the p.o.v. of the user of a generic WebDAV server, I'd expect custom properties to be supported.
sure. but the aim of the dav implementations in jackrabbit is to provide a thin dav-layer to the reference implementation of the jsr170 repository. from my understanding webdav is a protocol and therefore just one way to look at any kind content that is accessible by a 'repository' which provides some sort of api. even more, there could be various ways to take a webdav-look at the same repository (be it jsr170 compliant or something totally different) revealing different aspects or different levels of granularity. saying this explains, why there is a dav-library that tries to abstract the functionality required by the protocol and offers interfaces to implement a thin dav-view on top of a repository (again using 'repository' in a general sense not focus on JSR170). and finally this was one of reason not to follow the initial attempt to use slide, which from my understanding makes the protocol reign the repository. Brian wrote: > because data is persisted by the simple server as nt:folder and > nt:file nodes, there's no way to store custom properties on a webdav > resource or collection. this is not totally correct: - its a configuration issue that nt:file serves as non-collection by default. for a simple dav-view on top of the jsr170 reference implementation this definitely makes sense. - how a MKCOL and a PUT is translated to the calls on the JCR170 repository is a matter of the IOManager used for import/export. the IOManager again can be configured. - basically for level 1,2 compliance you would not have to create your own DavResource implementation. additional RFC have not be implemented for the simple stuff as noone claimed for it (see mail conversation with jeremi). Julian Reschke wrote:
I think it would be interesting to come up with a plan that would avoid that distinction.
no. the 2 implementations are distinct. if you are looking for some sort of webdav-support, forget about the remoting part (what we called 'jcr-server'). this is not as gary possibly thinks the attempt to do jsr170 - <network> - webdav instead the aim is to do jsr170 - network - jsr170 it would be equally possible to use http1.1 without webdav extensions and remote the jsr170 calls by GET and PUT having any kind of proprietary request body format. again: webdav is the protocol only.
A "common" server like that would be a fully compliant (or as compliant as possible) server, and the JCR functionality that doesn't map properly would be hidden somehow from generic clients.
yes one could built such a 'server'. but then you have to make sure your underlaying JSR170 repository supports the nodetypes you are defining in order to support e.g. full PROPPATCH support. and you are forcing the repository to be version-enabled if you define your generic-dav-server to be compliant to DeltaV. even further: JSR170 does not define how access control is modeled. having a dav-server supporting RFC 3744 you will end up defining how the repository behaves. regards angela ps: i'll take a look at your litmus findings. thanks for pointing this out.
