So I think we should really replace the current implemenation with the new one.
@Felix can you do the move please? Carsten 2014/1/17 Justin Edelson <[email protected]> > Hi Carsten, > FWIW, what you are describing looks like what I would expect to happen > - features are applied at the thread level, so any activity within > that thread would have the same features. > > Regards, > Justin > > On Fri, Jan 17, 2014 at 11:10 AM, Carsten Ziegeler <[email protected]> > wrote: > > 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 <[email protected]> > > > >> 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 > > [email protected] > -- Carsten Ziegeler [email protected]
