Sling CRUD with content versioning, API architecture

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Sling CRUD with content versioning, API architecture

Bruce Edge
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?
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.
Does the sling API recognize a mix:versionable node, and if so, how is it treated differently.

-Bruce

Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Robert Munteanu-2
On Tue, Dec 30, 2014 at 5:47 PM, Bruce Edge
<[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Bertrand Delacretaz
On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Felix Meschberger-3
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 <[hidden email]>:
>
>> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Bruce Edge
In reply to this post by Bertrand Delacretaz
>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>



Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Bruce Edge
>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

Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Street, Brian
Any specifications would need to handle:

 *   node name collisions
 *   Valid version “discovery”
 *   “relative” versions (i.e. get the previous version)


From: Bruce Edge <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Thursday, January 15, 2015 at 23:25
To: users <[hidden email]<mailto:[hidden email]>>
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.
Reply | Threaded
Open this post in threaded view
|

RE: Sling CRUD with content versioning, API architecture

Jason Bailey
In reply to this post by Felix Meschberger-3
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:[hidden email]]
Sent: Thursday, January 15, 2015 10:23 AM
To: <[hidden email]>
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 <[hidden email]>:
>
>> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sling CRUD with content versioning, API architecture

Dirk Rudolph-2
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 <[hidden email]> 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:[hidden email] <javascript:;>]
> Sent: Thursday, January 15, 2015 10:23 AM
> To: <[hidden email] <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 <
> [hidden email] <javascript:;>>:
> >
> >> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <[hidden email]
> <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

[hidden email] | www.netcentric.biz