Hi Mike, Sorry for all the flak you're getting - this JCR vs. other providers thing is probably at the core of that, so thanks for bringing it up.
On Wed, Mar 6, 2013 at 3:43 PM, Mike Müller <[email protected]> wrote: >...One thing which was never taken in account > is that Sling is not only a frontend for JCR (maybe in the old days this > was the case). Sling has different resource providers beside the JCR > provider like providers for files, bundles, servlets, etc... That's a very good point. At some point when we created Sling we made a conscious decision to target it as the web layer for JCR repositories. I still believe that was a good idea at the time, in 2008 the java web frameworks space was very crowded and it was good to differentiate. Now, it's probably right that today Sling is too good to be limited to JCR repositories ;-) Carsten's recent work on writable Resources already goes in the direction of making Sling fully usable with non-JCR content stores, and fully going in this direction might help more people adopt Sling. > ...It's not about JCR-ACLs or ResourceAccessGate and it doesn't weak > any existing security rules, that's definitely not true. It is also not about > having ACLs on different layers. It's just about to give an easy to use > service to sling users which do not only rely on JCR alone or want to > define a rule over different providers at a single place.... I agree with that, so then why not go all the way and provide an extension point that's clearly about re-implementing ACLs at the Resource or ResourceProvider level? A ResourceAccessControl service that's meant to *fully* take over access control - maybe your current gate proposal can do that, and it's just a matter of clarifying the role and terminology. So maybe we could a) Add extension points that allow OSGi services to fully take over access control, starting from the assumption that the underlying ResourceProviders are fully open b) Disable these features by default, as the default use case is still to use a JCR repository, and when doing that people shouldn't add another access control layer (that's IMO what causes pushback on your current proposal) c) Add some examples, tests and docs that show how to use Sling on different content stores, and how you might need to handle access control yourself in such cases Making it clear that Sling has two major modes, JCR (with repository-based access control) and non-JCR (with do-it-yourself access control) would probably help all of us who don't like the current proposals. -Bertrand
