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