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: FYI: feature flags prototype
On Fri, Nov 15, 2013 at 7:51 AM, Dominik Süß dominik.su...@gmail.com wrote: Am 14.11.2013 23:11 schrieb Alexander Klimetschek aklim...@adobe.com: ...And the ResourceDecorator can't filter out things? No, returning null skips tehe decoration and returns the original resource. You could hide properties but you'd additionally have to handle such resources in applicationcode... Yes, the ResourceDecorator can supply a synthetic resource with a resource type that points to a do-nothing renderer. The more we discuss this, the more I feel we don't need more than something along the lines of my prototype, in the Sling core. Additional modules like a specialized access gate or resource decorators in contrib are fine, but I'd like to keep the changes minimal in core, as people will need time to figure exactly where and how this is useful. -Bertrand
Re: FYI: feature flags prototype
Hi Bertrand, sure you could deliver a synthetic resource, but anyways you would have this resource in Resource.listChildren() - this is why I said that you then would need to make sure all your application code is aware of this possibility. The idea to keep the core free from additional code was the reason why I did think of access gates as an already existing hook that provides matching functionallity (filtering the resourcetree based on codable accessrules). I still think it is important to have such support since most features coded in sling are content(/resource)-driven so a switch that just acts in the javacode will in my eyes not be sufficient to be usable. (I just had such a scenario in a project where we had a really hard time to setup the corresponding ACLs to activate and deactivate the feature by groupmemberships) Best regards Dominik On Fri, Nov 15, 2013 at 9:27 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, Nov 15, 2013 at 7:51 AM, Dominik Süß dominik.su...@gmail.com wrote: Am 14.11.2013 23:11 schrieb Alexander Klimetschek aklim...@adobe.com : ...And the ResourceDecorator can't filter out things? No, returning null skips tehe decoration and returns the original resource. You could hide properties but you'd additionally have to handle such resources in applicationcode... Yes, the ResourceDecorator can supply a synthetic resource with a resource type that points to a do-nothing renderer. The more we discuss this, the more I feel we don't need more than something along the lines of my prototype, in the Sling core. Additional modules like a specialized access gate or resource decorators in contrib are fine, but I'd like to keep the changes minimal in core, as people will need time to figure exactly where and how this is useful. -Bertrand
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
Re: FYI: feature flags prototype
Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it Do we need any changes to Sling or to this new API to enable that? The problem IMO is that this makes the whole thing less transparent than using feature flags in the rendering code. OTOH if people can implement it themselves (and add the corresponding info to RequestProgressTracker) for transparency, I don't mind. -Bertrand
Re: FYI: feature flags prototype
+1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a
Re: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: ...One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR... I agree that we shouldn't bake feature flags deep into Sling, at least not right now until we see how people use them. If a ResourceResolver is generally useful, that might be a good option. -Bertrand
Re: FYI: feature flags prototype
On Wed, Nov 13, 2013 at 1:06 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Robert, On Tue, Nov 12, 2013 at 5:38 PM, Robert Munteanu rob...@lmn.ro wrote: ...1. I am typically wary of using Strings and am thinking that Enums would be a nice fit for feature flags... I see your point, what's the reason? Performance? Risk of typos? ...how about having a FeatureFlag marker interface and them enums can implement it?... The problem (and this isn't visible in my too contrived examples for now) is that the feature flag names will mostly be defined by configurations IMO. For example, if you have a feature flag set by a cookie with a specific value, the config would be: cookie name=foo value=bar feature flag name=foobar.cookie And another instance of the same service would have different config values and needs a unique feature flag ID. Do you see a way of generating enums with unique and discoverable values for such a case? Hm, no. Given this use cases I think that Strings are fine. Robert -- Sent from my (old) computer
RE: FYI: feature flags prototype
To confirm what Dominik mentioned: The existing ResourceAccessGate would allow to grant or deny access to resources. IMHO there's no need to implement another interface or hook to achieve what is requested in the perspective of granting or denying access to resources based on feature flag. Just implement a FeatureFlagResourceGate (or whatever name would make sense).. best regards Mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Thursday, November 14, 2013 1:07 PM To: dev Subject: Re: FYI: feature flags prototype +1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared
Re: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote: ...Just implement a FeatureFlagResourceGate (or whatever name would make sense).. My earlier question was, can one do this without any changes to Sling besides providing a way to find if a given feature is enabled, like in my prototype? I think the answer is yes, and if is is I wouldn't worry about it - let users implement that themselves to start with, but don't put anything in Sling for now besides the raw FeatureFlags (or Feature) service. Then, if common use cases emerge that need something in Sling, implement that - but cross that bridge once we get there. -Bertrand
Re: FYI: feature flags prototype
Hi Bertrand, I disagree on that one - maybe we should put it in contrib or so, but is is essential to disable most features to disable some parts of the resourcetree. This is just applying your api in a conventient api to resource resolving. There is no additional magic since developers would have to set the flag in the content anyways. As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Best regards Dominik On Thu, Nov 14, 2013 at 2:03 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote: ...Just implement a FeatureFlagResourceGate (or whatever name would make sense).. My earlier question was, can one do this without any changes to Sling besides providing a way to find if a given feature is enabled, like in my prototype? I think the answer is yes, and if is is I wouldn't worry about it - let users implement that themselves to start with, but don't put anything in Sling for now besides the raw FeatureFlags (or Feature) service. Then, if common use cases emerge that need something in Sling, implement that - but cross that bridge once we get there. -Bertrand
Re: FYI: feature flags prototype
Hi Sure you can do it, but it (a) doesn’t match the idea of an access gate (at least not in my little brain cells) and (b) it is not comprehensive since the JCR Resource Provider does not leverage that. (b) is IMHO the one reason breaking the idea. I like the idea of a decoration hook. Yet: it might have to be implemented somewhat differently because we don’t just want to have or have not a resource. In some cases we want to fall back to a resource with a lower „priority“ such as a resource furhter in the search path sequence. Just having a decorating hook would not solve this issue. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 23:56 schrieb Mike Müller mike...@mysign.ch: To confirm what Dominik mentioned: The existing ResourceAccessGate would allow to grant or deny access to resources. IMHO there's no need to implement another interface or hook to achieve what is requested in the perspective of granting or denying access to resources based on feature flag. Just implement a FeatureFlagResourceGate (or whatever name would make sense).. best regards Mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Thursday, November 14, 2013 1:07 PM To: dev Subject: Re: FYI: feature flags prototype +1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application
Re: FYI: feature flags prototype
Hi Agreed: Sling should come with a support for Feature-based resource filtering (or however we call that mechanism) and it should be on the same level (contrib or bundles) as the Features feature itself. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 15.11.2013 um 00:11 schrieb Dominik Süß dominik.su...@gmail.com: Hi Bertrand, I disagree on that one - maybe we should put it in contrib or so, but is is essential to disable most features to disable some parts of the resourcetree. This is just applying your api in a conventient api to resource resolving. There is no additional magic since developers would have to set the flag in the content anyways. As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Best regards Dominik On Thu, Nov 14, 2013 at 2:03 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote: ...Just implement a FeatureFlagResourceGate (or whatever name would make sense).. My earlier question was, can one do this without any changes to Sling besides providing a way to find if a given feature is enabled, like in my prototype? I think the answer is yes, and if is is I wouldn't worry about it - let users implement that themselves to start with, but don't put anything in Sling for now besides the raw FeatureFlags (or Feature) service. Then, if common use cases emerge that need something in Sling, implement that - but cross that bridge once we get there. -Bertrand
Re: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 2:37 PM, Felix Meschberger fmesc...@adobe.com wrote: ...Agreed: Sling should come with a support for Feature-based resource filtering (or however we call that mechanism) and it should be on the same level (contrib or bundles) as the Features feature itself... ok, ok...makes sense ;-) -Bertrand
Re: FYI: feature flags prototype
Hi Felix, see my comments inline. Best regards Dominik On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger fmesc...@adobe.comwrote: Hi Sure you can do it, but it (a) doesn’t match the idea of an access gate (at least not in my little brain cells) and (b) it is not comprehensive since the JCR Resource Provider does not leverage that. (b) is IMHO the one reason breaking the idea. Although I disagree on a (what else is this but restriction of access (don't mix it with permission by default) if b is the case (so it could not be granted to act on the global resource Tree I agree this would be a no go I like the idea of a decoration hook. Yet: it might have to be implemented somewhat differently because we don’t just want to have or have not a resource. In some cases we want to fall back to a resource with a lower „priority“ such as a resource furhter in the search path sequence. Just having a decorating hook would not solve this issue. Why is that? The searchpath isn't influenced at all, it is just that in one of the locations a specific verison is not there. What on the other hand could break is a superType chain, but This is something the developer should be aware when implementing. (given that decoration could be removal as well) Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 23:56 schrieb Mike Müller mike...@mysign.ch: To confirm what Dominik mentioned: The existing ResourceAccessGate would allow to grant or deny access to resources. IMHO there's no need to implement another interface or hook to achieve what is requested in the perspective of granting or denying access to resources based on feature flag. Just implement a FeatureFlagResourceGate (or whatever name would make sense).. best regards Mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Thursday, November 14, 2013 1:07 PM To: dev Subject: Re: FYI: feature flags prototype +1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require
RE: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger fmesc...@adobe.comwrote: Hi Sure you can do it, but it (a) doesn’t match the idea of an access gate (at least not in my little brain cells) and (b) it is not comprehensive since the JCR Resource Provider does not leverage that. (b) is IMHO the one reason breaking the idea. Although I disagree on a (what else is this but restriction of access (don't mix it with permission by default) if b is the case (so it could not be granted to act on the global resource Tree I agree this would be a no go The ResourceAccessGate could be used for every resource provider, it's only not configured for JCRResourceProvider (but could by just setting a flag in the OSGi configuration). The good reason for not enabling it is that ACLs of the JCR shouldn't be mixed up with custom ACLs. But in the use case of enabling features or not, ResourceAccessGate could be a lean solution to hide some resources and does not mix up with ACLs. best regards mike
Re: FYI: feature flags prototype
On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote: As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Wouldn't you just filter those requests out on a high level, e.g. using a servlet filter? Which can already be provided in a modular fashion by an optional featureflags module. Cheers, Alex
Re: FYI: feature flags prototype
Hi Alex, this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. Best regards, Dominik On Thu, Nov 14, 2013 at 10:48 PM, Alexander Klimetschek aklim...@adobe.comwrote: On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote: As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Wouldn't you just filter those requests out on a high level, e.g. using a servlet filter? Which can already be provided in a modular fashion by an optional featureflags module. Cheers, Alex
Re: FYI: feature flags prototype
Roy Fielding's presentation on the subject may also be interesting http://www.slideshare.net/royfielding/evolve13-keynote-scrambled-eggs page 36 to 45 Ruben On 11/14/2013 1:55 PM, Dominik Süß wrote: Hi Alex, this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. Best regards, Dominik On Thu, Nov 14, 2013 at 10:48 PM, Alexander Klimetschek aklim...@adobe.comwrote: On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote: As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Wouldn't you just filter those requests out on a high level, e.g. using a servlet filter? Which can already be provided in a modular fashion by an optional featureflags module. Cheers, Alex
Re: FYI: feature flags prototype
On 14.11.2013, at 13:55, Dominik Süß dominik.su...@gmail.com wrote: this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. I see. And the ResourceDecorator can't filter out things? Cheers, Alex
Re: FYI: feature flags prototype
Am 14.11.2013 23:11 schrieb Alexander Klimetschek aklim...@adobe.com: On 14.11.2013, at 13:55, Dominik Süß dominik.su...@gmail.com wrote: this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. I see. And the ResourceDecorator can't filter out things? No, returning null skips tehe decoration and returns the original resource. You could hide properties but you'd additionally have to handle such resources in applicationcode but having it really jidden. Best regards Dominik
[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
Re: FYI: feature flags prototype
Hi Bertrand, it looks cool indeed! I agree it'd be nice to enable feature flags also on the resource (even if I'm not too much convinced access gates are a good fit for it) and service level, and design the API for that too. However I'm not sure how that could be done for services in general, maybe it's overkill at this stage ? My 2 cents, Tommaso 2013/11/12 Bertrand Delacretaz bdelacre...@apache.org Hi, FYI I have created a minimal prototype [2] of how I'd see feature flags in Sling, as suggested a while ago by Henry Saginor in SLING-3148. The slides at [1], that Tommaso tweeted today, are full of good ideas about this. -Bertrand [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
Re: FYI: feature flags prototype
Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it Do we need any changes to Sling or to this new API to enable that? The problem IMO is that this makes the whole thing less transparent than using feature flags in the rendering code. OTOH if people can implement it themselves (and add the corresponding info to RequestProgressTracker) for transparency, I don't mind. -Bertrand
Re: FYI: feature flags prototype
Hi Robert, On Tue, Nov 12, 2013 at 5:38 PM, Robert Munteanu rob...@lmn.ro wrote: ...1. I am typically wary of using Strings and am thinking that Enums would be a nice fit for feature flags... I see your point, what's the reason? Performance? Risk of typos? ...how about having a FeatureFlag marker interface and them enums can implement it?... The problem (and this isn't visible in my too contrived examples for now) is that the feature flag names will mostly be defined by configurations IMO. For example, if you have a feature flag set by a cookie with a specific value, the config would be: cookie name=foo value=bar feature flag name=foobar.cookie And another instance of the same service would have different config values and needs a unique feature flag ID. Do you see a way of generating enums with unique and discoverable values for such a case? ...2. Background services don't have access to a request but would probably still use feature flags. What would be a way around that?... I'll reply to Tommaso's similar question. -Bertrand
Re: FYI: feature flags prototype
Hi Tommaso, On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: ...I agree it'd be nice to enable feature flags also on the resource (even if I'm not too much convinced access gates are a good fit for it) and service level, and design the API for that too I thought about that (and Robert has a similar question above) and I'm not sure what the best option is. We might go for three isEnabled methods: isEnabled(T featureFlagID, SlingHttpServletRequest request) isEnabled(T featureFlagID, Resource resource) isEnabled(T featureFlagID) But that means all FeatureFlagsProviders need to implement all three methods, and some of them might not be relevant. Or create three provider interfaces, one for each signature above, and the FeatureFlags service sorts the providers according to which interfaces they implement. Another option is /** @param context can be null */ isEnabled(T featureFlagID, Object context) Which requires FeatureFlagsProviders to use downcasting, not fantastic either. I agree with the need for feature flag providers to react to different types of contexts, not sure how to implement that...any suggestions? -Bertrand
Re: FYI: feature flags prototype
Hi Bertrand Thanks. This looks like a promising start. I have some comments, though ;-) 1. My first reaction to the SlingHttpServletRequest argument was: Why an argument ? Why not a ThreadLocal managed by the actual service with the help of a request filter ? (ok, what to do with non-request services). 2. I think the Providers should just register their known feature names as string-service properties. Could there be more than one supported feature actually ? Or is it really just a single one ? When using a service registration property we can start with single-string and switch to multi-value later without changing the API. 3. Configuration: This is a good point brought up by Dominik: We want to have central/singular configuration for the feature flags not spread them amongst tons of providers. And we have configuration which is global (static) and we have configuration which is per-user/group/time-of-day/random/whatever. 4. Thinking about it: these providers actually just evaluate an expression based on some configuration and some comparison object. Maybe there is a better term than „Provider“ for these things. 5. I understand FeatureFlags is actually the service we are interested in: - How about calling that just Feature with then call „Feature.isEnabled(FeatureX)“ then ? - We should expose the Feature Service in the SlingBindings - We should expose the Feature Service in the sling:defineObjects tag - we should probably expose the Feature Service in some sling:feature JSP tag 6. Re. Enums: On first sight this looks like a good idea. But it has the drawback that it generates a package wiring dependency and requires the ENUMs to be exported as API. What is the worst case szenarion of mis-typing a feature ? I think, the feature will just never be enabled. (ok, another one is that another unrelated feature might be enabled due to the typo — which could be mitigated by stipulating features to have reasonably distinct names). Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 13.11.2013 um 02:52 schrieb Bertrand Delacretaz bdelacre...@apache.org: Hi, FYI I have created a minimal prototype [2] of how I'd see feature flags in Sling, as suggested a while ago by Henry Saginor in SLING-3148. The slides at [1], that Tommaso tweeted today, are full of good ideas about this. -Bertrand [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
Re: FYI: feature flags prototype
Hi Just a stupid idea: public final class Context { public static Context from(SlingHttpServletRequest req) { return new Context(req, ...); } ... final SlingHttpServletRequest req; private Context(SlingHttpServletRequest req, ...) { this.req = req; } public SlingHttpServletRequest getRequest() { return this.req; } ... } And isEnabled(String name, Context); Or public interface FeatureServer { Features getFeatures(Context); } public interface Features { boolean isEnabled(String name); } (and the thing exposed in the SlingBindings (and thus the feature tag and the defineObjects tag) would be the Features object retrieved from the FeatureServer using the current request context. Regards Felix Am 13.11.2013 um 22:13 schrieb Bertrand Delacretaz bdelacre...@apache.org: Hi Tommaso, On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: ...I agree it'd be nice to enable feature flags also on the resource (even if I'm not too much convinced access gates are a good fit for it) and service level, and design the API for that too I thought about that (and Robert has a similar question above) and I'm not sure what the best option is. We might go for three isEnabled methods: isEnabled(T featureFlagID, SlingHttpServletRequest request) isEnabled(T featureFlagID, Resource resource) isEnabled(T featureFlagID) But that means all FeatureFlagsProviders need to implement all three methods, and some of them might not be relevant. Or create three provider interfaces, one for each signature above, and the FeatureFlags service sorts the providers according to which interfaces they implement. Another option is /** @param context can be null */ isEnabled(T featureFlagID, Object context) Which requires FeatureFlagsProviders to use downcasting, not fantastic either. I agree with the need for feature flag providers to react to different types of contexts, not sure how to implement that...any suggestions? -Bertrand
Re: FYI: feature flags prototype
Hi Am 13.11.2013 um 23:12 schrieb Felix Meschberger fmesc...@adobe.com: Hi Bertrand Thanks. This looks like a promising start. I have some comments, though ;-) 1. My first reaction to the SlingHttpServletRequest argument was: Why an argument ? Why not a ThreadLocal managed by the actual service with the help of a request filter ? (ok, what to do with non-request services). 2. I think the Providers should just register their known feature names as string-service properties. Could there be more than one supported feature actually ? Or is it really just a single one ? When using a service registration property we can start with single-string and switch to multi-value later without changing the API. 3. Configuration: This is a good point brought up by Dominik: We want to have central/singular configuration for the feature flags not spread them amongst tons of providers. And we have configuration which is global (static) and we have configuration which is per-user/group/time-of-day/random/whatever. 4. Thinking about it: these providers actually just evaluate an expression based on some configuration and some comparison object. Maybe there is a better term than „Provider“ for these things. 5. I understand FeatureFlags is actually the service we are interested in: - How about calling that just Feature with then call „Feature.isEnabled(FeatureX)“ then ? - We should expose the Feature Service in the SlingBindings - We should expose the Feature Service in the sling:defineObjects tag - we should probably expose the Feature Service in some sling:feature JSP tag 6. Re. Enums: On first sight this looks like a good idea. But it has the drawback that it generates a package wiring dependency and requires the ENUMs to be exported as API. What is the worst case szenarion of mis-typing a feature ? I think, the feature will just never be enabled. (ok, another one is that another unrelated feature might be enabled due to the typo — which could be mitigated by stipulating features to have reasonably distinct names). I forgot 7. FeatureFlagsProvider (or however it will be called) should just return boolean (scalar) not a wrapper. If the provider is called with an unsupported/unknown feature, it should just return false. This makes the code simpler, I think. Regards Felix Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 13.11.2013 um 02:52 schrieb Bertrand Delacretaz bdelacre...@apache.org: Hi, FYI I have created a minimal prototype [2] of how I'd see feature flags in Sling, as suggested a while ago by Henry Saginor in SLING-3148. The slides at [1], that Tommaso tweeted today, are full of good ideas about this. -Bertrand [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
Re: FYI: feature flags prototype
Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it Do we need any changes to Sling or to this new API to enable that? The problem IMO is that this makes the whole thing less transparent than using feature flags in the rendering code. OTOH if people can implement it themselves (and add the corresponding info to RequestProgressTracker) for transparency, I don't mind. -Bertrand
Re: FYI: feature flags prototype
Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it Do we need any changes to Sling or to this new API to enable that? The problem IMO is that this makes the whole thing less transparent than using feature flags in the rendering code. OTOH if people can implement it themselves (and add the corresponding info to RequestProgressTracker) for transparency, I don't mind. -Bertrand
Re: FYI: feature flags prototype
Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it Do we need any changes to Sling or to this new API to enable that? The problem IMO is that this makes the whole thing less transparent than using feature flags in the rendering code. OTOH if people can implement it themselves (and add the corresponding info to RequestProgressTracker) for transparency, I don't mind. -Bertrand
FYI: feature flags prototype
Hi, FYI I have created a minimal prototype [2] of how I'd see feature flags in Sling, as suggested a while ago by Henry Saginor in SLING-3148. The slides at [1], that Tommaso tweeted today, are full of good ideas about this. -Bertrand [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
Re: FYI: feature flags prototype
Hi Bertrand, as far as I can see the API is just covering the java aspect of this. When looking at typical Apache Sling-based Applications you might want to toggle specific resources from being renderes (this could be on page or on a lower resource level). Since this is a lot about permission to access these features I had the thought this is a case where the accessgates might be suitable where you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it. WDYT? --- Dominik On Tue, Nov 12, 2013 at 4:52 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, FYI I have created a minimal prototype [2] of how I'd see feature flags in Sling, as suggested a while ago by Henry Saginor in SLING-3148. The slides at [1], that Tommaso tweeted today, are full of good ideas about this. -Bertrand [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
Re: FYI: feature flags prototype
Hi Bertrand, On Tue, Nov 12, 2013 at 5:52 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, FYI I have created a minimal prototype [2] of how I'd see feature flags in Sling, as suggested a while ago by Henry Saginor in SLING-3148. Look cool! I have a couple of suggestions regarding the API: 1. I am typically wary of using Strings and am thinking that Enums would be a nice fit for feature flags. Of course, we can't declare them in our own API, since enum declarations can't be extended. But how about having a FeatureFlag marker interface and them enums can implement it? public interface FeatureFlag { } public enum MyAppFlags implements FeatureFlag { ENABLE_FEATURE_X, ENABLE_FEATURE_Y; } We can then invoke the FeatureFlags class: featureFlags.isEnabled(ENABLE_FEATURE_X, req); 2. Background services don't have access to a request but would probably still use feature flags. What would be a way around that? Robert The slides at [1], that Tommaso tweeted today, are full of good ideas about this. -Bertrand [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags -- Sent from my (old) computer