[
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.
