Yes, I can — Probably tomorrow, works ? Regards Felix
Am 20.01.2014 um 04:25 schrieb Carsten Ziegeler <cziege...@apache.org>: > 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 <jus...@justinedelson.com> > >> 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 <cziege...@apache.org> >> 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 <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 >> > > > > -- > Carsten Ziegeler > cziege...@apache.org
