You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2015/01/15 15:38:01 UTC
Re: Sling CRUD with content versioning, API architecture
On Tue, Dec 30, 2014 at 5:47 PM, Bruce Edge
<br...@nextissuemedia.com> wrote:
> I need to expose a CRUD API that allows the clients add new versions of existing content as well as retrieve older versions of content. This seems like something that has probably come up before so I was curious what the appropriate sling-like API looked like for a versioned content pool.
> I know that versioning is a JCR feature and not specifically associated with sling, but as sling is the JCR REST API, what, if any, versioning features are exposed from sling?
The Sling resource API does not expose any versioning features.
> I may have missed the sling docs on this, if so, please just point me to them.
> It feels wrong to code most of an app to sling's API, then reach around behind it to deal with the versioning aspect. What I've turned up so far seems to imply that this is what you have to do, i.e.: not use sling when dealing with versions.
You _might_ be able to get away with creating a new resource provider,
based on the jcr resource provider. That provider will use the
javax.jcr.version.VersionManager to return a Node-backed Resource for
the requested version.
Robert
> Does the sling API recognize a mix:versionable node, and if so, how is it treated differently.
>
> -Bruce
>
Re: Sling CRUD with content versioning, API architecture
Posted by Dirk Rudolph <di...@netcentric.biz>.
Why not using selectors in combination with a suffix?
GET information about existing versions
/path/to/resource.versions.json
GET a version
/path/to/resource.versions.json/versionA.json
POST to create a version
/path/to/resource.versions.ext
But nevertheless this improvement sounds quite interesting.
Regards,
On Friday, January 16, 2015, Jason Bailey <Ja...@sas.com> wrote:
> I was wondering about the rational for using parameters to display the
> version rather than using a selector. I would have thought a selector would
> be more inline (with my understanding) of using selectors to depict a
> variant of what the full path represents.
>
> If this is implemented. We would also need controls to disable. We have
> pages that we have no desire for external visitors to see prior versions.
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com <javascript:;>]
> Sent: Thursday, January 15, 2015 10:23 AM
> To: <users@sling.apache.org <javascript:;>>
> Subject: Re: Sling CRUD with content versioning, API architecture
>
> Hi
>
> We once discussed using path parameters for that, For example
> /some/resource;v=123 to select version 123. The JCR Resource Provider would
> have to be adapted for this. Depending on how we combine this with
> selectors and extensions the ResourceResolver as well.
>
> For the update, the POST servlet has support to create versions. There is
> no Resource based API for this, though.
>
> Regards
> Felix
>
> --
> Typos caused by my iPhone
>
> > Am 15.01.2015 um 16:08 schrieb Bertrand Delacretaz <
> bdelacretaz@apache.org <javascript:;>>:
> >
> >> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <rombert@apache.org
> <javascript:;>> wrote:
> >> ...You _might_ be able to get away with creating a new resource
> >> provider, based on the jcr resource provider....
> >
> > And if needed combine this with a set of selector-driven servlets.
> > POST to foo.V to create a version, GET foo.V.json to list them, etc.
> >
> > This comes up from time to time but for some reason it seems like no
> > one needed this enough to implement it so far. But that would be a
> > good addition to Sling IMO.
> >
> > -Bertrand
>
--
Dirk Rudolph | Senior Software Engineer
Netcentric AG
M: +41 79 642 37 11
D: +49 174 966 84 34
dirk.rudolph@netcentric.biz | www.netcentric.biz
RE: Sling CRUD with content versioning, API architecture
Posted by Jason Bailey <Ja...@sas.com>.
I was wondering about the rational for using parameters to display the version rather than using a selector. I would have thought a selector would be more inline (with my understanding) of using selectors to depict a variant of what the full path represents.
If this is implemented. We would also need controls to disable. We have pages that we have no desire for external visitors to see prior versions.
-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@adobe.com]
Sent: Thursday, January 15, 2015 10:23 AM
To: <us...@sling.apache.org>
Subject: Re: Sling CRUD with content versioning, API architecture
Hi
We once discussed using path parameters for that, For example /some/resource;v=123 to select version 123. The JCR Resource Provider would have to be adapted for this. Depending on how we combine this with selectors and extensions the ResourceResolver as well.
For the update, the POST servlet has support to create versions. There is no Resource based API for this, though.
Regards
Felix
--
Typos caused by my iPhone
> Am 15.01.2015 um 16:08 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
>> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <ro...@apache.org> wrote:
>> ...You _might_ be able to get away with creating a new resource
>> provider, based on the jcr resource provider....
>
> And if needed combine this with a set of selector-driven servlets.
> POST to foo.V to create a version, GET foo.V.json to list them, etc.
>
> This comes up from time to time but for some reason it seems like no
> one needed this enough to implement it so far. But that would be a
> good addition to Sling IMO.
>
> -Bertrand
Re: Sling CRUD with content versioning, API architecture
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
We once discussed using path parameters for that, For example /some/resource;v=123 to select version 123. The JCR Resource Provider would have to be adapted for this. Depending on how we combine this with selectors and extensions the ResourceResolver as well.
For the update, the POST servlet has support to create versions. There is no Resource based API for this, though.
Regards
Felix
--
Typos caused by my iPhone
> Am 15.01.2015 um 16:08 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
>> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <ro...@apache.org> wrote:
>> ...You _might_ be able to get away with creating a new resource provider,
>> based on the jcr resource provider....
>
> And if needed combine this with a set of selector-driven servlets.
> POST to foo.V to create a version, GET foo.V.json to list them, etc.
>
> This comes up from time to time but for some reason it seems like no
> one needed this enough to implement it so far. But that would be a
> good addition to Sling IMO.
>
> -Bertrand
Re: Sling CRUD with content versioning, API architecture
Posted by "Street, Brian" <br...@twcable.com>.
Any specifications would need to handle:
* node name collisions
* Valid version “discovery”
* “relative” versions (i.e. get the previous version)
From: Bruce Edge <br...@nextissuemedia.com>>
Reply-To: "users@sling.apache.org<ma...@sling.apache.org>" <us...@sling.apache.org>>
Date: Thursday, January 15, 2015 at 23:25
To: users <us...@sling.apache.org>>
Subject: Re: Sling CRUD with content versioning, API architecture
Anyone interested in doing this for a bounty?
I¹ve filed a jira new feature req. SLING-4318 - Sling resource API does
not expose any versioning features. [1]
Please contact me directly if interested.
-Bruce
[1] <https://issues.apache.org/jira/browse/SLING-4318>
Thinking about this feature a little more. What would be involved in
making content versions accessible from WebDAV?
Is there any convention for mapping versioned nodes to a filesystem?
One mount point that represented all versions would be problematic because
whatever naming convention one came up with for representing versions
could collide with actual filenames.
Could one create a mount point for different versions? If one created
version labels at a specific node level, could those be used as mount
points to access that version of the content as read/only data?
-Bruce
________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Sling CRUD with content versioning, API architecture
Posted by Bruce Edge <br...@nextissuemedia.com>.
>Anyone interested in doing this for a bounty?
>
>I¹ve filed a jira new feature req. SLING-4318 - Sling resource API does
>not expose any versioning features. [1]
>Please contact me directly if interested.
>
>-Bruce
>
>[1] <https://issues.apache.org/jira/browse/SLING-4318>
>
Thinking about this feature a little more. What would be involved in
making content versions accessible from WebDAV?
Is there any convention for mapping versioned nodes to a filesystem?
One mount point that represented all versions would be problematic because
whatever naming convention one came up with for representing versions
could collide with actual filenames.
Could one create a mount point for different versions? If one created
version labels at a specific node level, could those be used as mount
points to access that version of the content as read/only data?
-Bruce
Re: Sling CRUD with content versioning, API architecture
Posted by Bruce Edge <br...@nextissuemedia.com>.
>This comes up from time to time but for some reason it seems like no
>one needed this enough to implement it so far. But that would be a
>good addition to Sling IMO.
>
>-Bertrand
Anyone interested in doing this for a bounty?
I¹ve filed a jira new feature req. SLING-4318 - Sling resource API does
not expose any versioning features. [1]
Please contact me directly if interested.
-Bruce
[1] <https://issues.apache.org/jira/browse/SLING-4318>
Re: Sling CRUD with content versioning, API architecture
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...You _might_ be able to get away with creating a new resource provider,
> based on the jcr resource provider....
And if needed combine this with a set of selector-driven servlets.
POST to foo.V to create a version, GET foo.V.json to list them, etc.
This comes up from time to time but for some reason it seems like no
one needed this enough to implement it so far. But that would be a
good addition to Sling IMO.
-Bertrand