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