You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2018/10/02 11:59:08 UTC
Sling Type System: started a wiki page for concepts, ideas, motivation
Hi,
Recent discussions with a number of people from the Sling community
[1] have helped clarify my thoughts about this, I have started a wiki
page at https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements
and feedback is welcome, on that page or here.
Roughly, the goal is to create a Sling Type System that defines much
more precisely what the various Resource Types can contain, how they
work together, etc. with the goal of generating self-describing
interfaces.
Let's see where this leads, it's just rough ideas so far but it feels
like a useful unifying concept for Sling.
-Bertrand
[1] along with reading "a conversation with Alan Kay, creator of
Smalltalk" - https://queue.acm.org/detail.cfm?id=1039523
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Robert Munteanu <ro...@apache.org>.
Hi Jason,
Top-posting to sort of give a summary of my personal opinion: it's
absolutely fine to experiment with new resource providers and
extensions to the resource provider API.
Looking forward to a discussion when we have more concrete stuff to
talk about :-)
Thanks,
Robert
On Mon, 2018-11-26 at 11:11 -0500, Jason E Bailey wrote:
> I see similarities between Sling and projects such as MySql and
> MongoDB. In both of these the code that actually persists the data is
> a separate application, sometimes maintained by completely different
> people. In the case of MySQL you had a choice between MyISAM and
> InnoDB and they had different capabilities and it was up to the
> needs of the administrator to determine which one to use.
>
> I agree with your statement that we don't build dedicated persistence
> engines, but that's a very different statement to supporting the
> integration of various persistence engines, and/or implementing the
> layer that allows interaction with a given engine.
>
> I'm not sure what you were discussing, but my view of ordering comes
> down to this
>
> 1. A Resource Provider may support ordering the children of any
> particular resource
> 2. It's up to an implementer to understand whether a Resource
> Provider supports ordering and when it's appropriate
> 3. Ordering on a merged Resource Provider results in undefined
> behaviour
>
> Your concern with multiple providers and how the handle ordering is
> valid but is an existing issue. If I have a merged view with JCR
> resource provider and a non-jcr resource provider which supports
> CRUD. How does that work if I add content to the non-jcr provider to
> the children of an ordered jcr node?
>
> Of course, I'm fine with iteration, as long as we call it out that
> doing X and Y isn't defined I'd move forward, but I can understand
> how some would be reluctant.
>
> - Jason
>
>
> > I think there's an important note to be added here. Jackrabbit/Oak
> > are
> > dedicated to building persistence engines. Sling is a web
> > framework. I
> > am not saying that we can't build persistence engines or that we
> > can't
> > pull up features from Oak, but that's going to be hard :-)
> >
> > To make things even more interesting, concerns moved at the
> > resource
> > provider level need to be consistent between resource providers,
> > something that Oak does not have to care about.
> >
> > As a quick example, Radu and myself had a short chat some weeks ago
> > about what it would take to add ordering at the Sling level. While
> > it
> > would not be _that_ hard to add some basic support at the resource
> > provider level, things go downhill once you start ordering things
> > between providers, e.g.
> >
> > - ordering fails for provider 1, succeeds for provider 2 (two-phase
> > commit anyone?)
> > - two providers with inconsistent ordering properties are mounted
> > in
> > the same sling instance
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Jason E Bailey <je...@apache.org>.
I see similarities between Sling and projects such as MySql and MongoDB. In both of these the code that actually persists the data is a separate application, sometimes maintained by completely different people. In the case of MySQL you had a choice between MyISAM and InnoDB and they had different capabilities and it was up to the needs of the administrator to determine which one to use.
I agree with your statement that we don't build dedicated persistence engines, but that's a very different statement to supporting the integration of various persistence engines, and/or implementing the layer that allows interaction with a given engine.
I'm not sure what you were discussing, but my view of ordering comes down to this
1. A Resource Provider may support ordering the children of any particular resource
2. It's up to an implementer to understand whether a Resource Provider supports ordering and when it's appropriate
3. Ordering on a merged Resource Provider results in undefined behaviour
Your concern with multiple providers and how the handle ordering is valid but is an existing issue. If I have a merged view with JCR resource provider and a non-jcr resource provider which supports CRUD. How does that work if I add content to the non-jcr provider to the children of an ordered jcr node?
Of course, I'm fine with iteration, as long as we call it out that doing X and Y isn't defined I'd move forward, but I can understand how some would be reluctant.
- Jason
> I think there's an important note to be added here. Jackrabbit/Oak are
> dedicated to building persistence engines. Sling is a web framework. I
> am not saying that we can't build persistence engines or that we can't
> pull up features from Oak, but that's going to be hard :-)
>
> To make things even more interesting, concerns moved at the resource
> provider level need to be consistent between resource providers,
> something that Oak does not have to care about.
>
> As a quick example, Radu and myself had a short chat some weeks ago
> about what it would take to add ordering at the Sling level. While it
> would not be _that_ hard to add some basic support at the resource
> provider level, things go downhill once you start ordering things
> between providers, e.g.
>
> - ordering fails for provider 1, succeeds for provider 2 (two-phase
> commit anyone?)
> - two providers with inconsistent ordering properties are mounted in
> the same sling instance
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2018-10-10 at 10:09 -0400, Jason E Bailey wrote:
> On Wed, Oct 10, 2018, at 8:36 AM, Robert Munteanu wrote:
>
> > I think that's an important point, this should live on the Sling
> > level.
> > For the sake of being complete, there are also Oak restrictions
> > that
> > sort of overlap the scope of this initiative, see for instance [1].
> >
> This is a side note.
>
> This brings up a point that I've been formulating around the
> relationship of sling and the JCR. Which is similar to the discussion
> that's been occurring with security.
>
> For historical perspective, Sling has passed responsibility for
> certain concepts to the JCR such as types and security. Going forward
> because there is a need for resource providers other than the JCR, it
> makes sense to move these concepts upwards into the Sling layer.
I think there's an important note to be added here. Jackrabbit/Oak are
dedicated to building persistence engines. Sling is a web framework. I
am not saying that we can't build persistence engines or that we can't
pull up features from Oak, but that's going to be hard :-)
To make things even more interesting, concerns moved at the resource
provider level need to be consistent between resource providers,
something that Oak does not have to care about.
As a quick example, Radu and myself had a short chat some weeks ago
about what it would take to add ordering at the Sling level. While it
would not be _that_ hard to add some basic support at the resource
provider level, things go downhill once you start ordering things
between providers, e.g.
- ordering fails for provider 1, succeeds for provider 2 (two-phase
commit anyone?)
- two providers with inconsistent ordering properties are mounted in
the same sling instance
---------------------------
Again, not saying that we should not do it, just that we have to be
careful about how to do it. And that it would make sense to keep what
have in Oak, as it's been used over and over and battle-tested.
Thanks,
Robert
>
> This now introduces an issue where, at a high level, we have two
> different ways of doing 'x'.
>
> Options
> 1. Leave the way of implementing of 'x' to the resource provider.
> With Sling providing a failover way of handling it if the resource
> provider doesn't
> 2. Make all new resource providers provision it the Sling way.
> Leaving the jcr oak implementation alone.
> 3. Make the Sling way, the official way, and eventually all resource
> providers, including the jcr oak resource provider must support the
> sling way of doing things.
>
> IMHO, the third option is the way to go.
>
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Jason E Bailey <je...@apache.org>.
On Wed, Oct 10, 2018, at 8:36 AM, Robert Munteanu wrote:
> I think that's an important point, this should live on the Sling level.
> For the sake of being complete, there are also Oak restrictions that
> sort of overlap the scope of this initiative, see for instance [1].
>
This is a side note.
This brings up a point that I've been formulating around the relationship of sling and the JCR. Which is similar to the discussion that's been occurring with security.
For historical perspective, Sling has passed responsibility for certain concepts to the JCR such as types and security. Going forward because there is a need for resource providers other than the JCR, it makes sense to move these concepts upwards into the Sling layer.
This now introduces an issue where, at a high level, we have two different ways of doing 'x'.
Options
1. Leave the way of implementing of 'x' to the resource provider. With Sling providing a failover way of handling it if the resource provider doesn't
2. Make all new resource providers provision it the Sling way. Leaving the jcr oak implementation alone.
3. Make the Sling way, the official way, and eventually all resource providers, including the jcr oak resource provider must support the sling way of doing things.
IMHO, the third option is the way to go.
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2018-10-10 at 14:20 +0200, Bertrand Delacretaz wrote:
> On Wed, Oct 10, 2018 at 2:12 PM Jason E Bailey <je...@apache.org>
> wrote:
> ...
> > 1. If a resource does not declare a type is there a default one?
> > ...
>
> I don't have an opinion on this so far.
>
> > 2. How does the sling type differ from the jcr node types and how
> > will they co-exist?
>
> I think the Sling Type System should be independent from JCR, to be
> able to run on various storage backends.
I think that's an important point, this should live on the Sling level.
For the sake of being complete, there are also Oak restrictions that
sort of overlap the scope of this initiative, see for instance [1].
Thanks,
Robert
[1]: https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Oct 10, 2018 at 2:12 PM Jason E Bailey <je...@apache.org> wrote:
...
> 1. If a resource does not declare a type is there a default one? ...
I don't have an opinion on this so far.
> 2. How does the sling type differ from the jcr node types and how will they co-exist?
I think the Sling Type System should be independent from JCR, to be
able to run on various storage backends.
-Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Jason E Bailey <je...@apache.org>.
On Wed, Oct 10, 2018, at 5:54 AM, Bertrand Delacretaz wrote:
> On Tue, Oct 9, 2018 at 6:34 PM Jason E Bailey <je...@apache.org> wrote:
> Good point, I think it's analogous to casting an object in Java and
> should be subject to similar rules.
Or how interfaces work in golang where you just need to meet the field requirements.
Questions
1. If a resource does not declare a type is there a default one?
2. How does the sling type differ from the jcr node types and how will they co-exist?
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Oct 9, 2018 at 6:34 PM Jason E Bailey <je...@apache.org> wrote:
> ...in the RequestDispatcherOptions which is used by the sling:include taglib, you can force an overwrite of a resourceType to something else...
Good point, I think it's analogous to casting an object in Java and
should be subject to similar rules.
I have added a "Notes from other discussions" section with this note
at https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements
-Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Jason E Bailey <je...@apache.org>.
On Tue, Oct 9, 2018, at 8:46 AM, Bertrand Delacretaz wrote:
> Not sure what you mean by "apply other resourceTypes", do you mean by
> changing the sling:resourceType property?
>
Specifically, in the RequestDispatcherOptions which is used by the sling:include taglib, you can force an overwrite of a resourceType to something else.
Which is amazingly useful, but I wanted to point that out specifically, since I'm not changing the property. I'm changing what is used in the resourceType resolution.
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Jason,
On Wed, Oct 3, 2018 at 2:44 PM Jason E Bailey <je...@apache.org> wrote:
> ...A resource can have a sling:resourceType which defines the process which processes the resource. That is the default process, however
> you can apply other resourceTypes to that resource so it's processed differently based on your need....
Not sure what you mean by "apply other resourceTypes", do you mean by
changing the sling:resourceType property?
Then ok, you can do that now and as you say the scripts and servlets
wired to the new resource type will do their best to handle it.
> ...By assigning types to the resourceType you can define required/optional fields and the types of actions that can occur on that resource...
Yes that's the idea.
>
> This will then give you the ability to do the following
> 1. generate meta data about the resource for use with a UI
> 2. potentially used as a field validation if someone attempts to create a resource type without the proper fields
> 3. Will generate an error if they use something like sling:include to override the default resourceType and the new resourceType requires properties that the resource doesn't have....
Yes, sounds reasonable!
-Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Jason E Bailey <je...@apache.org>.
Let me see how close I am to your thought process.
A resource can have a sling:resourceType which defines the process which processes the resource. That is the default process, however you can apply other resourceTypes to that resource so it's processed differently based on your need.
To me that makes it more like an OO interface.
Right now, you can apply any resourceType to any resource and it will attempt to handle it. Even if the values on the resource that the resourceType requires aren't there.
By assigning types to the resourceType you can define required/optional fields and the types of actions that can occur on that resource.
This will then give you the ability to do the following
1. generate meta data about the resource for use with a UI
2. potentially used as a field validation if someone attempts to create a resource type without the proper fields
3. Will generate an error if they use something like sling:include to override the default resourceType and the new resourceType requires properties that the resource doesn't have.
How am I doing?
- Jason
On Tue, Oct 2, 2018, at 10:15 AM, Bertrand Delacretaz wrote:
> Hi Jason,
>
> thanks for your feedback!
>
> On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey <je...@apache.org> wrote:
> > ...To restate. Given a resource, you should be able to define what properties that resource can contain and what child resources it can be the parent of...
>
> Yes, among other things including some that we might discover along the way.
>
> > ...1. There's some things that are implicit. For example, stating that a resource can be a parent of a resource would imply
> > that you could perform the action to create the child resource....
>
> Absolutely, which means we can generate hyperlinks for such operations
> automatically.
>
> >... We're still a REST platform, do we need to have actions that are different then the standard REST methods? Would we have something different?...
>
> I think actions can be more specific, at least in terms of their
> link:rel values.
>
> A hyperlink can say
>
> link:rel=sling.create.imagefolder, method=POST, path=./images
>
> as basically it, along with the Sling Type System (STS) typedef, needs
> to contain enough information to generate an HTML form when generating
> a UI.
>
> maybe...just thinking outloud, but basically an action can have a more
> specific name than POST to clarify what it does exactly.
>
> > ...Looking at the code, I get confused between a type for a resource and a sling:resourceType. I believe these are different things....
>
> I think it's fair to describe the code as a hack created when those
> ideas where still emerging ;-)
>
> My point of view is that a resourceType points to an STS typedef,
> which conceptually points to rendering scripts or servlets.
>
> That's conceptually...in practice I think we can keep the current
> script resolution mechanism, but the STS typedef might validate
> operations before passing them on.
>
> Does that address your concerns?
>
> That's all still vague for now anyway, needs to be defined more
> clearly and proven with prototypes.
>
> -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Jason,
thanks for your feedback!
On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey <je...@apache.org> wrote:
> ...To restate. Given a resource, you should be able to define what properties that resource can contain and what child resources it can be the parent of...
Yes, among other things including some that we might discover along the way.
> ...1. There's some things that are implicit. For example, stating that a resource can be a parent of a resource would imply
> that you could perform the action to create the child resource....
Absolutely, which means we can generate hyperlinks for such operations
automatically.
>... We're still a REST platform, do we need to have actions that are different then the standard REST methods? Would we have something different?...
I think actions can be more specific, at least in terms of their
link:rel values.
A hyperlink can say
link:rel=sling.create.imagefolder, method=POST, path=./images
as basically it, along with the Sling Type System (STS) typedef, needs
to contain enough information to generate an HTML form when generating
a UI.
maybe...just thinking outloud, but basically an action can have a more
specific name than POST to clarify what it does exactly.
> ...Looking at the code, I get confused between a type for a resource and a sling:resourceType. I believe these are different things....
I think it's fair to describe the code as a hack created when those
ideas where still emerging ;-)
My point of view is that a resourceType points to an STS typedef,
which conceptually points to rendering scripts or servlets.
That's conceptually...in practice I think we can keep the current
script resolution mechanism, but the STS typedef might validate
operations before passing them on.
Does that address your concerns?
That's all still vague for now anyway, needs to be defined more
clearly and proven with prototypes.
-Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas,
motivation
Posted by Jason E Bailey <je...@apache.org>.
+1 for the idea.
To restate. Given a resource, you should be able to define what properties that resource can contain and what child resources it can be the parent of.
Feedback:
1. There's some things that are implicit. For example, stating that a resource can be a parent of a resource would imply that you could perform the action to create the child resource.
2. Terminology
We're still a REST platform, do we need to have actions that are different then the standard REST methods? Would we have something different?
Looking at the code, I get confused between a type for a resource and a sling:resourceType. I believe these are different things. The resourceType defines how the data is rendered and the resourceType can be overridden. Where as the type of a resource as we are talking about defines it structure, without regard to how it's rendered. I hope these are different things :)
- Jason
On Tue, Oct 2, 2018, at 7:59 AM, Bertrand Delacretaz wrote:
> Hi,
>
> Recent discussions with a number of people from the Sling community
> [1] have helped clarify my thoughts about this, I have started a wiki
> page at
> https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements
> and feedback is welcome, on that page or here.
>
> Roughly, the goal is to create a Sling Type System that defines much
> more precisely what the various Resource Types can contain, how they
> work together, etc. with the goal of generating self-describing
> interfaces.
>
> Let's see where this leads, it's just rough ideas so far but it feels
> like a useful unifying concept for Sling.
>
> -Bertrand
>
> [1] along with reading "a conversation with Alan Kay, creator of
> Smalltalk" - https://queue.acm.org/detail.cfm?id=1039523