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