[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670035#action_12670035
]
Felix Meschberger commented on SLING-848:
-----------------------------------------
The point of using the URI parameter notation is based on a discussion I once
had with Roy Fielding about encoding the version of a JCR node in an URL. He
pointed me to this feature, which is also described in Section 3.3, Path, of
RFC 3986 [1].
I think, this functionality is as simple as it is flexible.
We also chose this option because we explicitly did not want to extend the API
at this point in time.
One thing, we might well consider in the future, is that we might add some
thing like a VersionSelector to the ResourceResolver, which is used by the
ResourceProviders to further select versions.
One thing to not forget about is, that this ;v= functionality is not only
supported for ResourceResolver.resolve but also for
ResourceResolver.getResource. Consquently, the ResourceResolver.map should
generate URI strings, which also contain the ;v= URI parameters in case the
resource is based on a certain version (of a Node or similar).
Maybe the Resource.getPath() should also include the ;v= parameter since it is
transparently supported by the ResourceResolver and its ResourceProviders.
Finally, the ResourceMetadata map should probably also contain the an entry
with key "v" and the respective value.
[1] http://www.faqs.org/rfcs/rfc3986.html
> Support getting versioned resources by using uri path parameters
> ----------------------------------------------------------------
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: JCR Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
