jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: Status of jcr-server
Date Wed, 05 Apr 2006 08:48:07 GMT
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.


Mime
View raw message