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
