Hi, Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
> On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger <[email protected]> > wrote: >> ...Actually: It turns out that doing a ResourceProviderDecorator right is >> quite complex given >> the potential combinations of ResourceProvider extensions that might have to >> be captured. >> For now I would even go as far as to drop the ResourceProviderDecorator idea >> alltogether.... > > Interesting...I'm totally confused now, is that conclusion based on > on-list discussions that I missed? I think that's start of my thread: Don't use ResourceProviderDecortator or some other non-mandatory thing to implement access control. Access control should be intrinsic to the ResourceProvider and the ResourceProvider should either leverage the underlying store (as the JCR ResourceProvider) or use a central service which Mike is now going after. > > I guess what we need is for whoever wants to work on this ("this" > being access control for non-JCR resource providers, which is IMO the > core topic here) to start by writing down use cases on which we can > agree, and we can then look at how to implement them. > > As I said before, adapting the JCR permissions model to Sling > resources would be my favorite way by far - that model is known to > work and we are familiar with it, no need to reinvent too many wheels. If we can implement Mike's new service ontop of JCR, I think we are fine, right ? I just don't want to nail non-JCR ResourceProviders onto JCR directly. That would be counter-productive. Regards Felix
