jcr-server webapp PROPFIND/PROPPATCH support

[Rob Owen <Ro...@sas.com>]

To make the WebDAV view (/repository or SimpleWebdavServlet) in the jcr-server webapp more general, it seems that PROPFIND should return all (or at least all user-defined) properties found on the node. At the moment it only returns pseudo-properties (essential WebDAV properties) that are created from node metadata. If there are user defined properties on these nodes then they should be returned in a PROPFIND request. I'm not sure how these would be identified, but might be something like any properties not defined in some namespaces (eg. nt, jcr, rep). At the moment, these properties will not exist as they cannot be set on the nodetypes created using this servlet (see below).

In order to support PROPPATCH, DAVResourceImpl was modified, but discovered it creates nt:folder nodes for WebDAV collections and nt:file nodes for WebDAV non-collection resources. These nodetypes do not allow additional properties to be set and so this in itself prevents PROPPATCH from working. Would the recommended route be to change the nodetypes created (eg. to nt:unstructured or something else) in order to be able to set arbitrary properties on the JCR nodes and thereby provide the ability to fully support WebDAV's PROPPATCH? 

Full support for PROPFIND/PROPPATCH is required for some existing WebDAV applications to use jackrabbit as the content repository. Any suggestions on the best route would be much appreciated.

Thanks,
Rob.

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> instead, i would define a project specific 'folder' and 'file' nodetype
> that allow to set specific (or any) properties.

ok, i can do that, but it seems to be forcing the burden of implementing 
what i believe to be generally expected behavior on every jcr-server 
user who wants that behavior. that doesn't seem right.

> btw: i would consider the dav: prefix to be reserved for those
> things defined with the various rfcs related to webdav.
> i would not use that for your nodetypes. microsoft tend to use
> the dav: prefix for everything they invent related to webdav
> and it doesn't make things very clear.

sure. resources and collections are defined in a webdav rfc ;) that's 
why i suggested dav:resource and dav:collection.

my implementation of the webdav ticket spec uses ticket:. similarly, my 
caldav and icalendar stuff use the obvious prefixes.

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Angela Schreiber <an...@day.com>]

> my plan is to define the node types dav:collection and dav:resource 
> which extend nt:folder and nt:file to allow user-defined properties.
> 
> angela etc, does this sound like a reasonable approach?

hm.... not sure, whether i like that. i think the terms
collection and non-collection resource used with the webdav
specification reflect an abstraction. it's up to the
implementation to define what makes a collection resource.
nodetypes on the other hand should - from my point of view -
define something meaningful.

or one step further: with deltaV additional resourcetypes
are defined (e.g. versionhistory)... no, i would rather not create
new nodetypes for webdav-resourcetypes.

instead, i would define a project specific 'folder' and 'file' nodetype
that allow to set specific (or any) properties.

regards
angela

btw: i would consider the dav: prefix to be reserved for those
things defined with the various rfcs related to webdav.
i would not use that for your nodetypes. microsoft tend to use
the dav: prefix for everything they invent related to webdav
and it doesn't make things very clear.

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Rob Owen wrote:

> In order to support PROPPATCH, DAVResourceImpl was modified, but discovered it creates nt:folder nodes for WebDAV collections and nt:file nodes for WebDAV non-collection resources. These nodetypes do not allow additional properties to be set and so this in itself prevents PROPPATCH from working. Would the recommended route be to change the nodetypes created (eg. to nt:unstructured or something else) in order to be able to set arbitrary properties on the JCR nodes and thereby provide the ability to fully support WebDAV's PROPPATCH? 

hey, i'll be working on this in the next few days myself.

my plan is to define the node types dav:collection and dav:resource 
which extend nt:folder and nt:file to allow user-defined properties.

angela etc, does this sound like a reasonable approach?

if you want to get to this before i do, great. please submit a patch :)

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> it's flexible, it works, but i'm not totally convinced.
> sorry... i thought, i would get used to it :).
> that's why i'd like to think about it. nothing to
> worry about. i just want to let you know, that i'd like
> to find out, whether there is no other solution, that
> would be suited.

no problem. hopefully whatever you come up with will be similarly 
flexible and extensible.

fwiw, xml-based configuration isn't nearly as important to me as the 
chain of responsibility pattern.

as we talked about earlier, the static singleton way of managing chains 
is uncomfortable and can be improved, but the ability to simply mix and 
match chain commands is very powerful.

in the next few days i'll be able to show off my icalendar import/export 
commands (a pair used for caldav clients and a pair specifically for 
apple's ical). hopefully this will be a good real world example of how 
chain is useful.

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Angela Schreiber <an...@day.com>]

hi brian

Brian Moseley wrote:
> out of control how? 

various requirements, that from my point of view
do not fit nicely together. that tends to end up
in a 'sammelsurium' (don't know that in english).

> i'm finding the chain design very flexible and 
> perfectly suited for my needs.

no doubt about that :)

it's flexible, it works, but i'm not totally convinced.
sorry... i thought, i would get used to it :).
that's why i'd like to think about it. nothing to
worry about. i just want to let you know, that i'd like
to find out, whether there is no other solution, that
would be suited.

regards
angela

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> ok. i'm done with that. but i'd like to test it
> a little (very little :) bit, before i send it
> to one of the commiters.

excellent thanks.

> i also added a first draft for filtering resouces
> by nodetype and name... and realized that i'd
> like to review the usage of command-chains for
> the export/import. but that's rather a long term
> issue. i have the impression that the simple webdav
> part is going to be out of control... there is
> always room for improvement, but i'd like to have
> that a little more coordinated and planned.

out of control how? i'm finding the chain design very flexible and 
perfectly suited for my needs.

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Angela Schreiber <an...@day.com>]

> i think that's a good compromise.

ok. i'm done with that. but i'd like to test it
a little (very little :) bit, before i send it
to one of the commiters.

i also added a first draft for filtering resouces
by nodetype and name... and realized that i'd
like to review the usage of command-chains for
the export/import. but that's rather a long term
issue. i have the impression that the simple webdav
part is going to be out of control... there is
always room for improvement, but i'd like to have
that a little more coordinated and planned.

regards
angela

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> SHOULD :)

heh, gotcha :)

> the name of the underlaying repository item cannot be altered, so
> i think its fine that PROPPATCH for this fails.

yeah, i understand. i have a use case in which the webdav resource name 
and display name need to be different, so pegging the display name to 
the jcr name doesn't work for me. but that's ok, i can provide my own 
node types.

> i suggest to add all jcr-properties present on the underlaying
> resource to the set of dav-properties present on the resource and
> an attempt to call setProperty on the simple DavResource will try
> to set them... so it would be possible to use the PROPPATCH with
> the given implementation... i will do that.

i think that's a good compromise.

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Angela Schreiber <an...@day.com>]

Brian Moseley wrote:
> Brian Moseley wrote:
> 
>> my understanding is that you should be able to set arbitrary 
>> properties on any resource that advertises support for PROPPATCH. but 
>> i might be wrong :)

SHOULD :)

> furthermore, what's your take on PROPPATCHing the DAV:displayname 
> property? it's not possible at the moment, but it seems like a standard 
> operation that any webdav client would expect to be able to do. i don't 
> believe that's a protected property.

sure, its not protected.

rfc says:

"Execution of the directives in this method is, of course, subject to 
access control constraints. DAV compliant resources SHOULD support the 
setting of arbitrary dead properties."

the name of the underlaying repository item cannot be altered, so
i think its fine that PROPPATCH for this fails.

i suggest to add all jcr-properties present on the underlaying
resource to the set of dav-properties present on the resource and
an attempt to call setProperty on the simple DavResource will try
to set them... so it would be possible to use the PROPPATCH with
the given implementation... i will do that.

regards
angela

ps: "DAV:" is defined to be the namespace uri.. not the prefix.
     thats what i attempted to write before.... ;)

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Brian Moseley wrote:

> my understanding is that you should be able to set arbitrary properties 
> on any resource that advertises support for PROPPATCH. but i might be 
> wrong :)

furthermore, what's your take on PROPPATCHing the DAV:displayname 
property? it's not possible at the moment, but it seems like a standard 
operation that any webdav client would expect to be able to do. i don't 
believe that's a protected property..

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> as far as i understood the rfc the server must understand
> PROPPATCH in order to be dav 1 and 2 compliant. but its possible
> that a given resource does not know any property to be set as
> it is the case with the nt:file nodes.

my understanding is that you should be able to set arbitrary properties 
on any resource that advertises support for PROPPATCH. but i might be 
wrong :)

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Angela Schreiber <an...@day.com>]

hi there

may i?

the current situation is this:
- the servlets (also SimpleWebdavServlet) can handle PROPPATCH
- the call setProperty on the resource created before by the
   resource-provider which can be set.
- the resources defines, how and if it handles setProperty calls.

- the DavResourceImpl in the simple packages does not allow
   any property to be set, because i didn't need it so far and
   because the 'nt:file' and 'nt:resource' nodes that are
   displayed as non-collection resources do not allow for this.
   no fancy reason otherwise.

it should be sufficient to create your own dav-resource.
if you have to extend the simple-servlet, there is probably
a bug... (btw: i did not make the effort to build a multistatus
in case of failure).

as far as i understood the rfc the server must understand
PROPPATCH in order to be dav 1 and 2 compliant. but its possible
that a given resource does not know any property to be set as
it is the case with the nt:file nodes.

regards
angela


Brian Moseley wrote:
> Tobias Bocanegra wrote:
> 
>> the default configuration of the import/export catalogs are in a
>> manner, that provide a more or less 'normal' fileserver. MKCOL creates
>> folders, PUT creates files. it is completely up to you to alter the
>> command chains for your purpose.
> 
> 
> it's not that simple, tho. SimpleWebdavServlet and DavResourceImpl have 
> to be extended to translate the missing protocol stuff to jcr. and as 
> rob pointed out, new node types need to be defined that allow 
> user-defined properties.
> 
> even if it was as simple as adding new chain commands, clearly multiple 
> people want to have full webdav class 1 support. that should be 
> available in jcr-server, even if it's provided by an extension (tho i 
> don't see the purpose in that).

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Brian Moseley <bc...@osafoundation.org>]

Tobias Bocanegra wrote:

> the default configuration of the import/export catalogs are in a
> manner, that provide a more or less 'normal' fileserver. MKCOL creates
> folders, PUT creates files. it is completely up to you to alter the
> command chains for your purpose.

it's not that simple, tho. SimpleWebdavServlet and DavResourceImpl have 
to be extended to translate the missing protocol stuff to jcr. and as 
rob pointed out, new node types need to be defined that allow 
user-defined properties.

even if it was as simple as adding new chain commands, clearly multiple 
people want to have full webdav class 1 support. that should be 
available in jcr-server, even if it's provided by an extension (tho i 
don't see the purpose in that).

Re: jcr-server webapp PROPFIND/PROPPATCH support

[Tobias Bocanegra <to...@gmail.com>]

hi rob,
the default configuration of the import/export catalogs are in a
manner, that provide a more or less 'normal' fileserver. MKCOL creates
folders, PUT creates files. it is completely up to you to alter the
command chains for your purpose.

cheers, tobi

On 7/20/05, Rob Owen <Ro...@sas.com> wrote:
> To make the WebDAV view (/repository or SimpleWebdavServlet) in the jcr-server webapp more general, it seems that PROPFIND should return all (or at least all user-defined) properties found on the node. At the moment it only returns pseudo-properties (essential WebDAV properties) that are created from node metadata. If there are user defined properties on these nodes then they should be returned in a PROPFIND request. I'm not sure how these would be identified, but might be something like any properties not defined in some namespaces (eg. nt, jcr, rep). At the moment, these properties will not exist as they cannot be set on the nodetypes created using this servlet (see below).
> 
> In order to support PROPPATCH, DAVResourceImpl was modified, but discovered it creates nt:folder nodes for WebDAV collections and nt:file nodes for WebDAV non-collection resources. These nodetypes do not allow additional properties to be set and so this in itself prevents PROPPATCH from working. Would the recommended route be to change the nodetypes created (eg. to nt:unstructured or something else) in order to be able to set arbitrary properties on the JCR nodes and thereby provide the ability to fully support WebDAV's PROPPATCH?
> 
> Full support for PROPFIND/PROPPATCH is required for some existing WebDAV applications to use jackrabbit as the content repository. Any suggestions on the best route would be much appreciated.
> 
> Thanks,
> Rob.
> 
> 


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---