2013/3/25 Alexander Klimetschek <[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. Yes we did this wrong - but obviously can't change this without breaking something.
> > 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. The API can't be used accidentally in that case - even if someone implements it, it's not used by JCR. Seriously, I can only follow all this wrath against this partially - we already have a a lot of API which can be abused and no one ever complained there. Even if we put this into a separate bundle, someone who is able to find this service and implement it, will definitely also be able to deploy another api bundle. So by splitting it up, we're not gaining anything but just spreading api which belongs together across bundles. Carsten > > Cheers, > Alex > -- Carsten Ziegeler [email protected]
