[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513525 ]
angela commented on JCR-388: ---------------------------- so... had a look at the changes and i found the following things. i already started modifying the patch a bit, so there is no need for a new one. just for the record: - DeltaVResourceImpl: compliance class should from my point of view also mention the Label feature - VersionableResourceImpl: the supported method set lists MERGE, UPDATE although the implementation is missing - VersionableResourceImpl: the DAV:predecessor-set property is missing - if upon retrieving version-history and version the returned resource does not implement the proper interface i would rather throw than returning null. - DavResourceFactoryImpl: since the simple server should work on top of any JCR repository i added a check if versioning is supported by the repository and act accordingly. all new resources extending from DavResourceImpl: - the DavResourceImpl checks if the properties have been initialized before. this check is missing. Since the time jeremi originally copied code from the jcr-server the simple server has been modified (see JCR-416): no exporting custom properties is delegated to the PropertyHandler. However, from my point of view it doesn't make sense to additionally export all the specific properties defined by nt:version and nt:versionhistory and mix:versionable. most of them are already covered by predefined DAV properties. Therefore: - VersionHandler should implements its own exportProperties method. - perhaps it makes sense to define a VersionHistoryHandler. otherwise they would be exported/imported by the DefaultHandler which probably doesn't make to much sense. - the DefaultHandler should skip the version specific properties. in addition: - the VersionHandler assumes that the nt:frozenNode contains a jcr:content node. That might be the case if nt:file nodes are put under version control. But since there might be other versionable nodes in the repository the handler should at least check if the jcr:content node exists. so far my changes. i would like to test them (and maybe find others), then provide another patch, so you can also verify that the changes still fit your needs before they get commited. one thing i didn't have time to look at (maybe rob or ed?): the DavResourceImpl uses the configuration to determine which items should be filtered out and should not appear in the webdav-view to the repository. by default the 'jcr' prefix is filtered. i wondered whether this could cause inconsistencies with the planned changes. finally, there is yet another thing that has not been taken into consideration by none of the patches so far (and for which i don't have a quick solution at hand): RFC 3253 defines a separate behaviour for version-controlled collections. However the current approach does not take into account whether a resource represents a collection or not. As soon as the corresponding repository node is of type mix:versionable the resource is exposed to be versionable as well. If we want to make the simple server to be compliant to RFC 3253 this should be addressed. i wouldn't mind if this would be done in a second step, but we should take a look at it. regards angela > add support for RFC 3253 to the simple server > --------------------------------------------- > > Key: JCR-388 > URL: https://issues.apache.org/jira/browse/JCR-388 > Project: Jackrabbit > Issue Type: New Feature > Components: webdav > Affects Versions: 0.9 > Reporter: jeremi Joslin > Assignee: angela > Priority: Minor > Attachments: patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, > Review.txt, rfc.zip > > > http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.