> From: Alexander Klimetschek [mailto:[email protected]] > On 25.03.2013, at 14:05, Carsten Ziegeler <[email protected]> wrote: > > > 2013/3/25 Alexander Klimetschek <[email protected]>: > >> > >> The crucial difference IMHO is that the sling API is meant for > >> applications. The > resource access security is a sling internal and optional one since for > application > code it is all transparent behind the resource resolver and resource API. > Therefore > it should go into a separate API bundle. > > > > That's wrong - we already have resource provider and co there > > Then this is IMHO bad design of the sling API bundle. I also note that the > ResourceProvider is also in the generic org.apache.sling.api.resource package > so it > can't be split out anymore - as a kind of SPI it should also package-wise be > decoupled from the application level interfaces... But let's not continue > with that > error for such an optional feature. > > The point is that if some application stack does not want to expose the > resource > access security stuff (because it uses JCR only and does not want application > devs > to see and use those APIs accidentally), it should be able to ship a system > without > them. By putting everything into the Sling API bundle this becomes impossible.
If the ResourceProvider interface is at the wrong place in the Sling API bundle and should be placed as an SPI somewhere in the resourceresolver bundle, that means that Sling encourages other implementations of ResourceResolver to expose their own different SPIs. I think the main goal here is, that Sling defines a simple way how resource providers can be attached to Sling (and not the ResourceResolver) - a Sling way which should be used. That's also the case with ResourceAccessSecurity. In this case if it is shipped with the Sling API and someone even implements this service, it is NOT used if the installation is only shiped with a JCR resouce provider. The ResourceAccessSecurity should it make easy to use providers without any ACLs without having to pass on some security - and that's a step forward for Sling. That's why I'm engaged to share here some code and ideas. I'm really a little bit confused about this occasionally offending discussion. I haven't yet got some feedback to the main proposal of this thread - unfortunately. Best regards Mike
