Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On 12.12.2013, at 19:40, Carsten Ziegeler cziege...@apache.org wrote: I think you missunderstood me, or we're maybe talking about different things - as repeatedly stated we don't need to change the resource resolver - we have everything in place; and now we exactly need to define the use cases to know how the flags api should look like and which possibilites it has. The implementation of that api can do all kinds of stuff like using thread locals to access the current request etc. Ah, sorry. I thought you'd define an API that the resource resolver impl would call directly. Cheers, Alex
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On 11.12.2013, at 19:10, Carsten Ziegeler cziege...@apache.org wrote: I think we're pretty clear now how we could implement this, basically everything is in place, so the resource resolver has all features we need in the way we need them. And we should now start defining the feature flags api. Did you read my post? ;) I don't see the open question on how dynamic those flags get into the resource resolver being answered, at least not here. I think it really makes sense to experiment with that in an existing service interface, let applications be written with that, and figure out what the use cases are, before bending the resource resolver in any direction. Cheers, Alex
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
I think you missunderstood me, or we're maybe talking about different things - as repeatedly stated we don't need to change the resource resolver - we have everything in place; and now we exactly need to define the use cases to know how the flags api should look like and which possibilites it has. The implementation of that api can do all kinds of stuff like using thread locals to access the current request etc. Carsten 2013/12/13 Alexander Klimetschek aklim...@adobe.com On 11.12.2013, at 19:10, Carsten Ziegeler cziege...@apache.org wrote: I think we're pretty clear now how we could implement this, basically everything is in place, so the resource resolver has all features we need in the way we need them. And we should now start defining the feature flags api. Did you read my post? ;) I don't see the open question on how dynamic those flags get into the resource resolver being answered, at least not here. I think it really makes sense to experiment with that in an existing service interface, let applications be written with that, and figure out what the use cases are, before bending the resource resolver in any direction. Cheers, Alex -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi I disagree ;-) For hiding resources I would really prefer hooking into the ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to have a strong position on that :-) ) As for changing the rendering, I would assume you primarily mean changing the resource type (or may be the resource super type), I agree ResourceDecorator is the way to go. Regards Felix Am 11.12.2013 um 01:00 schrieb Carsten Ziegeler cziege...@apache.org: So can we agree to continue with these two appraches: - global ResourceAccessSecurity for hidding resources - Decorator for changing rendering ? Carsten 2013/12/11 Bertrand Delacretaz bdelacre...@apache.org On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...it pays back that we had strong oponents of simply calling the ResourceAccessGate for every provider... If needed we could differentiate between global and per-provider ResourceAccessGates using service properties. -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi, On Wed, Dec 11, 2013 at 9:34 AM, Felix Meschberger fmesc...@adobe.com wrote: ...For hiding resources I would really prefer hooking into the ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to have a strong position on that :-) )... I reread your original post in this thread and I'm not fully convinced one way or the other. Making the ResourceResolver aware of feature flags directly seems to be too much coupling. Using ResourceAccessSecurity feels too granular - with feature flags we want to completely hide a resource, we don't care if it's for reading, writing or anything else - it just virtually stops existing. With ResourceAccessSecurity you need to implement too many methods to express that. Maybe a ResourceAccessVeto service, with a single vetoResourceAccess() method? -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
:) Ok, but the resource access stuff is deep in the resource resolver already and provides the exact functionality we need: hiding a resource under some conditions - so why adding a second implementation, doubling the complexity in this area just with the same functionality? Of course the service which defines whether a resource is visible or not should look much different and directly suited to the featureflags requirements - but implementation wise we can simple use the resource access gate stuff and provide an implementation in the core which triggers the FeatureFlag stuff Carsten 2013/12/11 Felix Meschberger fmesc...@adobe.com Hi I disagree ;-) For hiding resources I would really prefer hooking into the ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to have a strong position on that :-) ) As for changing the rendering, I would assume you primarily mean changing the resource type (or may be the resource super type), I agree ResourceDecorator is the way to go. Regards Felix Am 11.12.2013 um 01:00 schrieb Carsten Ziegeler cziege...@apache.org: So can we agree to continue with these two appraches: - global ResourceAccessSecurity for hidding resources - Decorator for changing rendering ? Carsten 2013/12/11 Bertrand Delacretaz bdelacre...@apache.org On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...it pays back that we had strong oponents of simply calling the ResourceAccessGate for every provider... If needed we could differentiate between global and per-provider ResourceAccessGates using service properties. -Bertrand -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
2013/12/11 Bertrand Delacretaz bdelacre...@apache.org Hi, On Wed, Dec 11, 2013 at 9:34 AM, Felix Meschberger fmesc...@adobe.com wrote: ...For hiding resources I would really prefer hooking into the ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to have a strong position on that :-) )... I reread your original post in this thread and I'm not fully convinced one way or the other. Making the ResourceResolver aware of feature flags directly seems to be too much coupling. Using ResourceAccessSecurity feels too granular - with feature flags we want to completely hide a resource, we don't care if it's for reading, writing or anything else - it just virtually stops existing. With ResourceAccessSecurity you need to implement too many methods to express that. Maybe a ResourceAccessVeto service, with a single vetoResourceAccess() method? Yepp, thanks that was actually my initial idea (though I didn't bring it across...) - we define this extra service for flags, but implementation wise this is wrapped by a resource access gate to avoid complicating the implementation Carsten -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Wed, Dec 11, 2013 at 10:00 AM, Carsten Ziegeler cziege...@apache.org wrote: 2013/12/11 Bertrand Delacretaz bdelacre...@apache.org ... Maybe a ResourceAccessVeto service, with a single vetoResourceAccess() method? Yepp, thanks that was actually my initial idea (though I didn't bring it across...) - we define this extra service for flags, but implementation wise this is wrapped by a resource access gate to avoid complicating the implementation... Works for me, good idea - as long as implementors just have to provide a simple API they don't need to care how it's done under the hood. -Bertrand
RE: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
From: Felix Meschberger fmesc...@adobe.com For hiding resources I would really prefer hooking into the ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to have a strong position on that :-) ) The problem of integrating that right into the resource resolver impl is that there is an unknown complexity in when those flags should be enabled or not. This might be whether this resource resolver is created from the request or not, certain user or other application conditions. Since it's a new idea, it isn't really clear yet. Thus it is IMO out of the question to add such unclear configurability to the resource resolver impl itself. Adding a dedicated service interface for that is better, as it at least decouples that from the impl and makes it possible to play around independently on the application level. However, the interface itself isn't clear yet - as mentioned, some things might depend on the context of how the resource resolver was created in the first place so it might be best to start playing around with the ResourceAccessGate (even if it is some more work atm) to see what the real needs are and to carve a new dedicated service interface etc. from there. As for changing the rendering, I would assume you primarily mean changing the resource type (or may be the resource super type), I agree ResourceDecorator is the way to go. I guess the feature flags need to do more... although it would be nice if you can reduce the use case to this and replace with a resource type that e.g. returns a 404 or does nothing (in case of an included resource). Cheers, Alex
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
I think we're pretty clear now how we could implement this, basically everything is in place, so the resource resolver has all features we need in the way we need them. And we should now start defining the feature flags api. Carsten 2013/12/12 Alexander Klimetschek aklim...@adobe.com From: Felix Meschberger fmesc...@adobe.com For hiding resources I would really prefer hooking into the ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to have a strong position on that :-) ) The problem of integrating that right into the resource resolver impl is that there is an unknown complexity in when those flags should be enabled or not. This might be whether this resource resolver is created from the request or not, certain user or other application conditions. Since it's a new idea, it isn't really clear yet. Thus it is IMO out of the question to add such unclear configurability to the resource resolver impl itself. Adding a dedicated service interface for that is better, as it at least decouples that from the impl and makes it possible to play around independently on the application level. However, the interface itself isn't clear yet - as mentioned, some things might depend on the context of how the resource resolver was created in the first place so it might be best to start playing around with the ResourceAccessGate (even if it is some more work atm) to see what the real needs are and to carve a new dedicated service interface etc. from there. As for changing the rendering, I would assume you primarily mean changing the resource type (or may be the resource super type), I agree ResourceDecorator is the way to go. I guess the feature flags need to do more... although it would be nice if you can reduce the use case to this and replace with a resource type that e.g. returns a 404 or does nothing (in case of an included resource). Cheers, Alex -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi, On Mon, Dec 9, 2013 at 11:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...do we have a wiki page where we collect real use cases for feature flags?... I've just created https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support for that. (don't expect too much...It just says TBD so far ;-) -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
I've been thinking about this a little bit, and as has been said ResourceDecorator is not the solution as this does not allow to hide a resource - we can't change this contract and I now implementations of the decorator relying on this. I think it has been mentioned as well, ResourceAccessGate does exactly what is needed for handling frags on resources - it filters and allows to return null (deny access) based on some implementation. So why aren't we using this? Carsten 2013/12/10 Bertrand Delacretaz bdelacre...@apache.org Hi, On Mon, Dec 9, 2013 at 11:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...do we have a wiki page where we collect real use cases for feature flags?... I've just created https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support for that. (don't expect too much...It just says TBD so far ;-) -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I think it has been mentioned as well, ResourceAccessGate does exactly what is needed for handling frags on resources - it filters and allows to return null (deny access) based on some implementation. So why aren't we using this?... IIRC the comments were that ResourceAccessGate has to be wired for each ResourceProvider - if there's a way to define global ResourceAccessGates that might work. I have added a few basic use cases at https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support, I guess we're mostly looking at show/hide Resources here which might cover alter resource rendering as well, but caching of rendering scripts is an issue. -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Am 10.12.2013 um 12:04 schrieb Bertrand Delacretaz bdelacre...@apache.org: On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I think it has been mentioned as well, ResourceAccessGate does exactly what is needed for handling frags on resources - it filters and allows to return null (deny access) based on some implementation. So why aren't we using this?... IIRC the comments were that ResourceAccessGate has to be wired for each ResourceProvider - if there's a way to define global ResourceAccessGates that might work. Right ResourceAccessGate was invented to support ResourceProvider services which do not do access control themselves. So it is an access control feature. I would like to keep feature flags separate from access control. Its a different domain with mostly different administrators: I don't think we should require user/acl karma to enable/disable feature flags. Regards Felix I have added a few basic use cases at https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support, I guess we're mostly looking at show/hide Resources here which might cover alter resource rendering as well, but caching of rendering scripts is an issue. -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Yes, now it pays back that we had strong oponents of simply calling the ResourceAccessGate for every provider... :( But we can reconsider this and are done. For alternate rendering we can use a resource decorator - instead of using different scripts for the same resource type, the decorator returns a resource which has a different resource type. This would require zero changes to the script handling. Carsten 2013/12/10 Felix Meschberger fmesc...@adobe.com Hi Am 10.12.2013 um 12:04 schrieb Bertrand Delacretaz bdelacre...@apache.org : On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I think it has been mentioned as well, ResourceAccessGate does exactly what is needed for handling frags on resources - it filters and allows to return null (deny access) based on some implementation. So why aren't we using this?... IIRC the comments were that ResourceAccessGate has to be wired for each ResourceProvider - if there's a way to define global ResourceAccessGates that might work. Right ResourceAccessGate was invented to support ResourceProvider services which do not do access control themselves. So it is an access control feature. I would like to keep feature flags separate from access control. Its a different domain with mostly different administrators: I don't think we should require user/acl karma to enable/disable feature flags. Regards Felix I have added a few basic use cases at https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support , I guess we're mostly looking at show/hide Resources here which might cover alter resource rendering as well, but caching of rendering scripts is an issue. -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...For alternate rendering we can use a resource decorator - instead of using different scripts for the same resource type, the decorator returns a resource which has a different resource type. This would require zero changes to the script handling Yes, that's what my HideResourceDecorator prototype [1] does. -Bertrand [1] http://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags/src/main/java/org/apache/sling/extensions/featureflags/api/HideResourceDecorator.java
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...it pays back that we had strong oponents of simply calling the ResourceAccessGate for every provider... If needed we could differentiate between global and per-provider ResourceAccessGates using service properties. -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
So can we agree to continue with these two appraches: - global ResourceAccessSecurity for hidding resources - Decorator for changing rendering ? Carsten 2013/12/11 Bertrand Delacretaz bdelacre...@apache.org On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler cziege...@apache.org wrote: ...it pays back that we had strong oponents of simply calling the ResourceAccessGate for every provider... If needed we could differentiate between global and per-provider ResourceAccessGates using service properties. -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi, On Sun, Dec 8, 2013 at 6:04 AM, Carsten Ziegeler cziege...@apache.org wrote: ...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 I agree. Another possibility is to use dynamic ACLs to show/hide resources to specific users/sessions based on feature flags, and according to [1] this should be possible at the Oak level. At this point I think it's fairly unclear how people are actually going to use feature flags, so if there's a way of prototyping that that doesn't require changes to the Sling core I'd go that route. Prototype in the simplest possible way (*), evaluate actual use cases and go back to the drawing board once we understand the whole thing better. -Bertrand [1] http://markmail.org/thread/7j7zkuwr6pa3ckql (*) which my SLING-3267 patch can also enable, that's still available there for experimenting even if we know that's not the final solution
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Good idea - do we have a wiki page where we collect real use cases for feature flags? Carsten 2013/12/10 Bertrand Delacretaz bdelacre...@apache.org Hi, On Sun, Dec 8, 2013 at 6:04 AM, Carsten Ziegeler cziege...@apache.org wrote: ...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 I agree. Another possibility is to use dynamic ACLs to show/hide resources to specific users/sessions based on feature flags, and according to [1] this should be possible at the Oak level. At this point I think it's fairly unclear how people are actually going to use feature flags, so if there's a way of prototyping that that doesn't require changes to the Sling core I'd go that route. Prototype in the simplest possible way (*), evaluate actual use cases and go back to the drawing board once we understand the whole thing better. -Bertrand [1] http://markmail.org/thread/7j7zkuwr6pa3ckql (*) which my SLING-3267 patch can also enable, that's still available there for experimenting even if we know that's not the final solution -- Carsten Ziegeler cziege...@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
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
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi, On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger fmesc...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements... I had another look at this, and the existing ResourceDecorator already plays a similar role as an extension point to do something to each Resource while it's being resolved. That's already baked in the resource resolver, so we can leverage it without requiring much code changes. ResourceDecorator.decorate(Resource r) returning null is currently only vaguely specified and certainly not used, as that causes NPEs in places - I think we just need to clarify that decorate returning null causes a Resource to be ignored, fix the code so that it's true and we're good. I have created SLING-3267 to track that, I'll create a patch for review there. -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Please don't mingle resource decoration with the feature flag. The use cases are different and returning null from the ResourceDecorator is clearly defined to be same as returning the same resource, i.e. no decoration at all. If this results in NPEs the calling code must be fixed. Feature flag is about optional hiding (or showing) resources. Decoration is about making the Resource appear differently. Also a ResourceDecorator does not solve the problem: Resource resolution effectively generates a (virtual) list of candidate resources and picks the first of this list to return. Adding feature flags to this actually may influence the selection from the list in that the first (or second or …) is ignored and the second (or third or …) is actually returned. Think back and forth I really think that we should put feature flag support into the ResourceResolver proper. I am opposed to changing API to implement a feature flag solution, which is not complete. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 06.12.2013 um 11:48 schrieb Bertrand Delacretaz bdelacre...@apache.org: Hi, On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger fmesc...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements... I had another look at this, and the existing ResourceDecorator already plays a similar role as an extension point to do something to each Resource while it's being resolved. That's already baked in the resource resolver, so we can leverage it without requiring much code changes. ResourceDecorator.decorate(Resource r) returning null is currently only vaguely specified and certainly not used, as that causes NPEs in places - I think we just need to clarify that decorate returning null causes a Resource to be ignored, fix the code so that it's true and we're good. I have created SLING-3267 to track that, I'll create a patch for review there. -Bertrand
RE: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi I'm not sure if it is a good idea that a ResourceDecorator could return null. IMHO it's not what someone would expect from a Decorator. All the more that decorator is the name of a well known pattern, which would never be a null object (only a null object could be decorated but not vice versa). best regards mike -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Friday, December 06, 2013 11:49 AM To: dev Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi, On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger fmesc...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements... I had another look at this, and the existing ResourceDecorator already plays a similar role as an extension point to do something to each Resource while it's being resolved. That's already baked in the resource resolver, so we can leverage it without requiring much code changes. ResourceDecorator.decorate(Resource r) returning null is currently only vaguely specified and certainly not used, as that causes NPEs in places - I think we just need to clarify that decorate returning null causes a Resource to be ignored, fix the code so that it's true and we're good. I have created SLING-3267 to track that, I'll create a patch for review there. -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
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
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
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
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
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
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Henry, the way understand Feature Flags as well as the comment from Roy is quite different: - Features can be content, java code, configuration or anything else that you would touch to introduce a new feature - Therefore the when a feature is turned off ist must be granted that (as far as technically possible) the feature has no impact on the behavior of the system (this might not be achivable since the only way of total removal of impact is not to release it, but the goal is to get as close as possible to this state) - Pure highlevel application checks cannot accomplish this since the plattform API would anyway call different logic and has to rely on the high level API to produce the same result (e.g. the resolutionprocess would be different between (a) the feature not being present at all (since there is no resource found) (b) the feature is disabled and a third logic (like a filter) needs to take care of this. I read Roy's comment that this is something required, but there is even more than that, like configuration which needs to be taken into account. But when looking at the area of resource resolving filtering the resourcetree in first place is as close as we can get to a similar behavior like non-existance. Best regards Dominik P.S. Isolation of JS logic isn't that hard, you just make sure that all plugins of a feature are included as one JS file. The hard part is request optimization where you might want to aggregate the plugins. This might be achivable by aggregations that have generated featurehashes in their URL (this way all users consuming the same featureset get the same aggregation so you still can cache). On Mon, Nov 18, 2013 at 11:43 PM, Henry Saginor hsagi...@gmail.com wrote: This is what I derive from your Roy's comments. It is not possible to predict all of the changes that might be conditioned via a flag. The context is really up to the application developers and their requirements. Applying feature flags at the resource level would only cover a particular set of changes. 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. Also, API for flag checking needs to be made available on both client and server without them calling each other. This can get tricky when we consider caching. On Nov 15, 2013, at 6:00 PM, Roy T. Fielding field...@gbiv.com wrote: On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote: On 15.11.2013, at 07:13, Amit.. Gupta. amitg...@adobe.com wrote: You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Ack. IMO feature flags are clearly a high-level application, not infrastructure, aspect. Feature flags are a mechanism for isolating changes within a deployed system. Any part of that system. That means a feature flag needs to be able to condition any change that might be made to a system, including any change to the configuration files/data, any change to code monitoring the system, any change to the selection of data sources, any change to content (including everything as content), any change to a layout within any page or component, any change to the order in which things are done, any change to a report about what was done, and any change I haven't mentioned yet short of physically walking up to the server rack and unplugging the power by hand. In short, if it is content, it can be made conditional on the basis of a feature flag. That is the granularity of feature flag use. Separate from that is the feature flag flip switch (i.e., the set of ways that a given feature can be turned on) and the extent to which a feature becomes sticky per user once enabled for that user. You should expect a typical deployed site to have on the order of 1024 active feature flags. Hence, think carefully before choosing a verbose (or linear) mechanism for checking or remembering flags. Likewise, you should expect to have both a global setting for each flag and a per-user mask, and the person running the flip switch control panel needs to be able to choose from a) off for all users b) off for unassigned users c) proportional assignment to on (X out of N users, max M) d) logical (custom code) assignment to on e) on for unassigned users f) on for all users and be able to remember assignments per user, without requiring the user to login, and without assigning more
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
This is what I derive from your Roy's comments. It is not possible to predict all of the changes that might be conditioned via a flag. The context is really up to the application developers and their requirements. Applying feature flags at the resource level would only cover a particular set of changes. 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. Also, API for flag checking needs to be made available on both client and server without them calling each other. This can get tricky when we consider caching. On Nov 15, 2013, at 6:00 PM, Roy T. Fielding field...@gbiv.com wrote: On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote: On 15.11.2013, at 07:13, Amit.. Gupta. amitg...@adobe.com wrote: You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Ack. IMO feature flags are clearly a high-level application, not infrastructure, aspect. Feature flags are a mechanism for isolating changes within a deployed system. Any part of that system. That means a feature flag needs to be able to condition any change that might be made to a system, including any change to the configuration files/data, any change to code monitoring the system, any change to the selection of data sources, any change to content (including everything as content), any change to a layout within any page or component, any change to the order in which things are done, any change to a report about what was done, and any change I haven't mentioned yet short of physically walking up to the server rack and unplugging the power by hand. In short, if it is content, it can be made conditional on the basis of a feature flag. That is the granularity of feature flag use. Separate from that is the feature flag flip switch (i.e., the set of ways that a given feature can be turned on) and the extent to which a feature becomes sticky per user once enabled for that user. You should expect a typical deployed site to have on the order of 1024 active feature flags. Hence, think carefully before choosing a verbose (or linear) mechanism for checking or remembering flags. Likewise, you should expect to have both a global setting for each flag and a per-user mask, and the person running the flip switch control panel needs to be able to choose from a) off for all users b) off for unassigned users c) proportional assignment to on (X out of N users, max M) d) logical (custom code) assignment to on e) on for unassigned users f) on for all users and be able to remember assignments per user, without requiring the user to login, and without assigning more than one cookie. Oh, and a flag check should be available for both server-side and client-side code, without calling the other side. Finally, for the ultimate effect, it ought to be possible to burn a flag by automating the removal of all conditionals within managed content that require that flag (change the content to permanently on) or the removal of all such conditions (permanently off). Cheers, Roy
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Amit, maybe I haven't understood the idea of FeatureFlags right, but isn't this exactly what this is about. The system should behave if it wouldn't be there at all. The basic idea is that you don't have to branch it away during development so you can ship it in a non-productionready or non QEed state and turn it on without deployment (maybe just to a smaler audience or in the beta env). Therefore I would expect this to be completely hidden as it would like when being protected through ACLs. Cheers Dominik On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. amitg...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. I think that we should not put it directly into ResourceResolver, because if resourceResolver does not give me a resource if feature is disabled, Resource will stop existing for me. There will be no way to access that resource using ResourceResolver api i.e. let's say I want to remove sling:feature attribute from that resource, I can't do that. ResourceResolverDecorator should be the way to go (implementation could be restricted i.e. queryResources not supported), additionally providing a servlet filter as Alex suggested. Thanks, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 15 November 2013 13:11 To: dev@sling.apache.org Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be filtered with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren - IteratorResource * getChildren - IterableResource * queryResources - IteratorMapString,Object * findResources - IteratorResource Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag - might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. IteratorResource can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected, if at all possible). Also: A ResourceDecorator cannot properly handle feature flags in /etc/map mappings at all and also support feature flags on resolveResource is probably hard to implement because the list of canidate resources is influence by /etc/map mappings so a decorator would have to replicate that work. * ResourceAccessGate: This is not leveraged by all ResourceProviders and we expressely leave it to these services to indicate the use of a gate. Defining Feature flag support to have all ResourceProviders require to leverage ResourceAccessGate sounds contradictionary. Also, while a case can be made for the Feature flag to be some kind of an access gate, the actual idea of the ResourceAccessGate is actual access control as in secure access. Also we just want to apply the feature flag gate to all Resourceproviders not a generic ACL gate which may also
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Am 16.11.2013 um 00:11 schrieb Amit.. Gupta. amitg...@adobe.com: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. I think that we should not put it directly into ResourceResolver, because if resourceResolver does not give me a resource if feature is disabled, Resource will stop existing for me. There will be no way to access that resource using ResourceResolver api i.e. let's say I want to remove sling:feature attribute from that resource, I can't do that. Ah ! Excellent point. Thanks. OTOH, a feature flag is there for a reason — hiding the resource if desired so. If your resource resolver happens to be affected, so be it.. I think that is a consequence. If you know, though, that the resource exists and is guarded by a feature flag, you can still make sure to temporarily enable the feature in your current context to remove the flag. Hmm, maybe a Feature.runWith(String feature, CallableT) to call a Callable with the named feature enabled would help ;-) ResourceResolverDecorator should be the way to go (implementation could be restricted i.e. queryResources not supported), additionally providing a servlet filter as Alex suggested. I am not in favor of having restricted implementations because this tends to result in inconsistent behaviour. Regards Felix Thanks, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 15 November 2013 13:11 To: dev@sling.apache.org Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be filtered with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren - IteratorResource * getChildren - IterableResource * queryResources - IteratorMapString,Object * findResources - IteratorResource Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag - might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. IteratorResource can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected, if at all possible). Also: A ResourceDecorator cannot properly handle feature flags in /etc/map mappings at all and also support feature flags on resolveResource is probably hard to implement because the list of canidate resources is influence by /etc/map mappings so a decorator would have to replicate that work. * ResourceAccessGate: This is not leveraged by all ResourceProviders and we expressely leave it to these services to indicate the use of a gate. Defining Feature flag support to have all ResourceProviders require to leverage ResourceAccessGate sounds contradictionary. Also, while a case can be made for the Feature flag to be some kind of an access gate, the actual idea
RE: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi, @Dominik, Some other use cases could be - free features vs premium/paid features, where some features are disabled based on type of user account. @Felix, You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Thanks, Amit -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: 15 November 2013 18:49 To: dev Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi Amit, maybe I haven't understood the idea of FeatureFlags right, but isn't this exactly what this is about. The system should behave if it wouldn't be there at all. The basic idea is that you don't have to branch it away during development so you can ship it in a non-productionready or non QEed state and turn it on without deployment (maybe just to a smaler audience or in the beta env). Therefore I would expect this to be completely hidden as it would like when being protected through ACLs. Cheers Dominik On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. amitg...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. I think that we should not put it directly into ResourceResolver, because if resourceResolver does not give me a resource if feature is disabled, Resource will stop existing for me. There will be no way to access that resource using ResourceResolver api i.e. let's say I want to remove sling:feature attribute from that resource, I can't do that. ResourceResolverDecorator should be the way to go (implementation could be restricted i.e. queryResources not supported), additionally providing a servlet filter as Alex suggested. Thanks, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 15 November 2013 13:11 To: dev@sling.apache.org Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be filtered with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren - IteratorResource * getChildren - IterableResource * queryResources - IteratorMapString,Object * findResources - IteratorResource Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag - might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. IteratorResource can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Amit, regarding your answer: this is at least not the spirit of feature flags, but this would work as well since the toggle could be based on specific groupmemberships or so. This would also solve the second part you mentioned - a user might even have permissions to toggle the switch for himself (the toggle it self obviously should not be protected by the feature ;) ). Such a mechanism would even match the scenario I just had where the feature is experimental and therefore could be activated by users/tenants that want to enable experimental features for their interface. (like google sometimes gives you the option to turn on/off a newer version of their interface for betatesting). Best regards Dominik On Fri, Nov 15, 2013 at 4:13 PM, Amit.. Gupta. amitg...@adobe.com wrote: Hi, @Dominik, Some other use cases could be - free features vs premium/paid features, where some features are disabled based on type of user account. @Felix, You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Thanks, Amit -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: 15 November 2013 18:49 To: dev Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi Amit, maybe I haven't understood the idea of FeatureFlags right, but isn't this exactly what this is about. The system should behave if it wouldn't be there at all. The basic idea is that you don't have to branch it away during development so you can ship it in a non-productionready or non QEed state and turn it on without deployment (maybe just to a smaler audience or in the beta env). Therefore I would expect this to be completely hidden as it would like when being protected through ACLs. Cheers Dominik On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. amitg...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. I think that we should not put it directly into ResourceResolver, because if resourceResolver does not give me a resource if feature is disabled, Resource will stop existing for me. There will be no way to access that resource using ResourceResolver api i.e. let's say I want to remove sling:feature attribute from that resource, I can't do that. ResourceResolverDecorator should be the way to go (implementation could be restricted i.e. queryResources not supported), additionally providing a servlet filter as Alex suggested. Thanks, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 15 November 2013 13:11 To: dev@sling.apache.org Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be filtered with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Fri, Nov 15, 2013 at 2:23 PM, Felix Meschberger fmesc...@adobe.com wrote: ...If you know, though, that the resource exists and is guarded by a feature flag, you can still make sure to temporarily enable the feature in your current context to remove the flag Yes, the idea is to support any way of enabling features: per-user, per-group, fully randomly, based on phases of the moon if you want. So Sling should not make assumptions about what turns a feature on or off - which does have impact on caching strategies, some of our cache might need to be made aware of the features flags, but not right now IMO - let's start simple. -Bertrand
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
let's say I want to remove sling:feature attribute from that resource, I can't do that I don't think that will be a real problem in practice. Removing the sling:feature property from a resource enables the feature. Therefore you may as well enable the feature (e.g. via configuration) before removing the property. The property only marks a resource as being restricted by a feature flag, it doesn't toggle the feature flag. Regards Julian On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. amitg...@adobe.com wrote: So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. I think that we should not put it directly into ResourceResolver, because if resourceResolver does not give me a resource if feature is disabled, Resource will stop existing for me. There will be no way to access that resource using ResourceResolver api i.e. let's say I want to remove sling:feature attribute from that resource, I can't do that. ResourceResolverDecorator should be the way to go (implementation could be restricted i.e. queryResources not supported), additionally providing a servlet filter as Alex suggested. Thanks, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 15 November 2013 13:11 To: dev@sling.apache.org Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be filtered with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren - IteratorResource * getChildren - IterableResource * queryResources - IteratorMapString,Object * findResources - IteratorResource Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag - might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. IteratorResource can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected, if at all possible). Also: A ResourceDecorator cannot properly handle feature flags in /etc/map mappings at all and also support feature flags on resolveResource is probably hard to implement because the list of canidate resources is influence by /etc/map mappings so a decorator would have to replicate that work. * ResourceAccessGate: This is not leveraged by all ResourceProviders and we expressely leave it to these services to indicate the use of a gate. Defining Feature flag support to have all ResourceProviders require to leverage ResourceAccessGate sounds contradictionary. Also, while a case can be made for the Feature flag to be some kind of an access gate, the actual idea of the ResourceAccessGate is actual access control as in secure access. Also we just want to apply the feature flag gate to all Resourceproviders not a generic ACL gate which may also be defined. * Bake Feature
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On 15.11.2013, at 07:13, Amit.. Gupta. amitg...@adobe.com wrote: You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Ack. IMO feature flags are clearly a high-level application, not infrastructure, aspect. Cheers, Alex
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote: On 15.11.2013, at 07:13, Amit.. Gupta. amitg...@adobe.com wrote: You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Ack. IMO feature flags are clearly a high-level application, not infrastructure, aspect. Feature flags are a mechanism for isolating changes within a deployed system. Any part of that system. That means a feature flag needs to be able to condition any change that might be made to a system, including any change to the configuration files/data, any change to code monitoring the system, any change to the selection of data sources, any change to content (including everything as content), any change to a layout within any page or component, any change to the order in which things are done, any change to a report about what was done, and any change I haven't mentioned yet short of physically walking up to the server rack and unplugging the power by hand. In short, if it is content, it can be made conditional on the basis of a feature flag. That is the granularity of feature flag use. Separate from that is the feature flag flip switch (i.e., the set of ways that a given feature can be turned on) and the extent to which a feature becomes sticky per user once enabled for that user. You should expect a typical deployed site to have on the order of 1024 active feature flags. Hence, think carefully before choosing a verbose (or linear) mechanism for checking or remembering flags. Likewise, you should expect to have both a global setting for each flag and a per-user mask, and the person running the flip switch control panel needs to be able to choose from a) off for all users b) off for unassigned users c) proportional assignment to on (X out of N users, max M) d) logical (custom code) assignment to on e) on for unassigned users f) on for all users and be able to remember assignments per user, without requiring the user to login, and without assigning more than one cookie. Oh, and a flag check should be available for both server-side and client-side code, without calling the other side. Finally, for the ultimate effect, it ought to be possible to burn a flag by automating the removal of all conditionals within managed content that require that flag (change the content to permanently on) or the removal of all such conditions (permanently off). Cheers, Roy
[OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be „filtered“ with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren - IteratorResource * getChildren - IterableResource * queryResources - IteratorMapString,Object * findResources - IteratorResource Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag — might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. IteratorResource can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected, if at all possible). Also: A ResourceDecorator cannot properly handle feature flags in /etc/map mappings at all and also support feature flags on resolveResource is probably hard to implement because the list of canidate resources is influence by /etc/map mappings so a decorator would have to replicate that work. * ResourceAccessGate: This is not leveraged by all ResourceProviders and we expressely leave it to these services to indicate the use of a gate. Defining Feature flag support to have all ResourceProviders require to leverage ResourceAccessGate sounds contradictionary. Also, while a case can be made for the Feature flag to be some kind of an access gate, the actual idea of the ResourceAccessGate is actual access control as in secure access. Also we just want to apply the feature flag „gate“ to all Resourceproviders not a generic ACL gate which may also be defined. * Bake Feature support into the ResourceResolver implementation: This solves the ResourceResolverDecorator problems by being able to handle Feature flags early. But is bears the problem of overloading the implementation with the feature flag support. So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. Is the ServletResolver also affected by feature flags ? Probably not: The ResourceResolver does filter on resource feature flags and the SlingScriptAdapterFactory may apply feature flags for scripting languages and Servlet services may implement OptingServlet and query feature flags in the accepts method. Regards Felix
