I can see how we can implement a global feature flag within the resource resolver easily, but as soon as there is some "randomness" involved, like enable it for specific users or N users etc. this really gets tricky. Script resolution would be at least one area causing troubles. As Ruben points out, in that case this looks very close to the old tenant support proposal years back from Felix.
Carsten 2013/12/7 Ruben Reusser <r...@headwire.com> > it may be worth it revisiting the tenant api in regards to feature flags > as well and have some sort of way to have feature flag dependent osgi > properties. > > Ruben > > > On 12/6/2013 12:51 PM, Justin Edelson wrote: > >> On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek >> <aklim...@adobe.com> wrote: >> >>> On 06.12.2013, at 08:08, Felix Meschberger <fmesc...@adobe.com> wrote: >>> >>> Think back and forth I really think that we should put feature flag >>>> support into the ResourceResolver proper. >>>> >>> I agree. >>> >> +1 >> >> Henry wrote it well: "So, fundamentally all that the framework can do >> is provide a way to define flags, provide a switch panel and a way to >> extend it, and API to check flags in condition statements. How and >> where each flag is used is up to the developer of a specific >> application feature." >> >> The ResourceResolver is such an application feature which needs to be >> enhanced to support feature flags. We probably have some others in >> Sling as well. >> >> Regards, >> Justin >> >> Another completely open question is: the resource resolver is not tied >>> to a request, backend services use it as well. So if the feature flag is >>> driven by the request, how do you handle that for those service resolvers? >>> >>> AFAIU, the two major cases for feature flags are a) user dependent and >>> b) global on/off. But in both cases it can depend on the application >>> whether those services have to fall under the flags or not. For example, >>> you might have an observation going on that does something advanced (*). >>> Should it run even if it's "feature" is off (as nobody will use the results >>> as long as the feature is off)? Or should it be totally disabled? This is a >>> question often only the application can decide. >>> >>> Say the service resolvers are using admin sessions or some service >>> users, then you could turn it on/off based on them - to be in line with >>> user-based request resolvers in case a). But it could also be that you have >>> flag a where you must handle it in application code and don't want it >>> handled in the resolver already. Thus you either make it configurable on >>> the flag itself what impact it has or you actually ask for a resource >>> resolver with special feature flags in the first place (or not, getting a >>> standard one). >>> >>> Also, I mentioned observation: it's a JCR level thing that wouldn't be >>> affected by Sling resource resolver feature flags. >>> >>> Just thinking out loud here, not sure what the cleanest approach would >>> be... >>> >>> Cheers, >>> Alex >>> >> > -- Carsten Ziegeler cziege...@apache.org
