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. >
