Hi Felix, thanks for taking this up - as briefly discussed offline I like this new approach. It's less API and better covers our use cases.
The only thing I'm not 100% sure is the evaluation of the features within the resource resolver. It gets the current client context from the features service, assuming this is set. For requests, this is the case - so that problem is solved. For internal resource resolvers this is different. As long as no request is running, an "empty" client context will be returned, but within a request the context belonging to the request is returned. This sounds like the right thing, because if some request invokes a different (long running) resource resolver, both see the same state (have the same features enabled) at that point of time. However for the long running ones this might be unexpected. I'm not sure if this poses are problem, just want to highlight this. Other than that, +1 for moving this to trunk :) Carsten 2014/1/17 Felix Meschberger <fmesc...@adobe.com> > Hi > > As I repeatedly said, I think the Feature Flags support should be > implemented without the ResourceAccessGate mechanism because it is not an > access control thing but a purely operational visibility thing. Also as > opposed to access control, feature flag enabled can and should be > controllable by a consumer of the API; for example by passing a request > parameter on the request. > > Based on the existing code, I have created a prototype in my whiteboard at > [1]: > > * On a per-resource level feature flags are set as sling:feature > properties of type String or String[] > * Flags are checked during resource resolution in the > ProviderHandler.getReadableResource method > * Feature services can implement ResourceDecorator such that they can > decorate a resource in case their feature is enabled. > > I also provided diffs in the feature-flags and resourceresolver projects > to be able to see, what has been changed. > > WDYT ? > > Regards > Felix > > [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags -- Carsten Ziegeler cziege...@apache.org
