jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Suggestion for PROPPATCH with simple-server (was: Status of jcr-server)
Date Thu, 06 Apr 2006 07:23:36 GMT

i'd like to summarize the problem we are currently
having with matching a PROPPATCH request to JSR170
compliant repository (specially the RI) and come up
with a suggested solution.

While setting properties on a JSR170 repository is
defined for any level2 compliant implementation and
therefore matches the requirements of webDAV, the
current simple server limits a PROPPATCH request
to a setProperty call on the top most node of the
item structure that represents the dav property.

The nt:file nodetype
As state before i think that given the nodetypes
available with jackrabbit, it is appropriate for
a default configuration to map nodes of nt:file
as non-collection dav-resources.
Except for a property jcr:created (inherited from
its supertype) this nodetype does not have or
allow additional properties. However, this nodetype
defines a jcr:content child node which can be
of any type. Due to the fact, that the default
handler uses nt:resource as nodetype for the jcr:content
child node the set of properties is limited (jcr:encoding,
jcr:lastModified, jcr:mimeType).

The import/export
The IOHandler interface allows to apply specific import/export
behaviour for different types of resource without
modification of the DavResource implementation.
Since every particular handler knows about the under-
lying item structure, it is in charge of retrieving
properties (e.g. mimetype, contentlength) as well.
However, setting properties is not delegated to the
handlers (see above).

Proposed solution

The situation described before leads me to the
following conclusion:

- IOHandler should not only read/write resource data
   and properties during GET, PUT, PROPFIND but should
   also take care of setting/removing properties without
   modifying the data during PROPPATCH.

- Since the previous suggestion would still limit
   the properties to (jcr:encoding, jcr:mimeType and
   jcr:lastModified), we may think about changing the
   default nodetype for the jcr:content node to

I guess this would meet the requirements for those
expecting a webDAV server that is (as a first step)
not limited regarding PROPPATCH. Second it would
allow to have a handling of property modifications
which is specific for individual resource types instead
of trying to set all properties to the uppermost node.

what do you think?

kind regards

View raw message