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
