jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
Date Wed, 18 Jul 2007 10:26:04 GMT

    [ 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
- VersionableResourceImpl: the supported method set lists MERGE, UPDATE although the implementation
- 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

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
  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
does not take into account whether a resource represents a collection or not. As soon as the
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.


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

View raw message