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. 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
