hi 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.
Description ----------------------------------------------------- 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 nt:unstructured. 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 angela
