Re: Sling Type System: started a wiki page for concepts, ideas, motivation

[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

[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

[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