Re: [featureflags] Readding sling:features to resourceResolver
I still think an utility method is the best/easiest approach. What is the real problem with doing that? Adding feature flag to the resource resolver requires to check a property for each and every resource access - and I don't see a good reason why this burden should be added for a use case which can be easily solved with an utility method. Usually feature flags are exactly implemented in this way - you add code with an if statement, checking whether the flag is enabled and then do something depending an that result. So why not starting with utlity code and only if that really becomes a problem (and again I don't see why it should), we can talk about changing things. We failed with adding this general mechanism and so far nothing has changed and we would run in the same problems again. Carsten 2014-06-16 10:01 GMT-04:00 Dominik Süß dominik.su...@gmail.com: Hi Bertrand, I'm not really about altering resource rendering but enable disable resources for rendering, so I probably wouldn't decorate the scripts and servlets but the resources that define those resourceTypes. This is what we all have done a lot when hiding away frontend for endusers (at least I know nobody who didn't have to do that once in a while) via ACLs wherever the UI was composed from resources. I get the case where you would like to alter the Script/Servlet that handles a resourceType but as you mentioned this comes with quite some constraints and locations that would require some changes to work. To get this working we would definitively need some script metadata which could also be added as annotation to be able to distinct on servletresolution. I do not like the term magic feature flags since it implies there would happen something out of control for a developert. Declarative feature flags is matching what I'm thinking of - declaring something being part of a feature and having a unified behavior of the system to handle these for the specific cases just as we have a declarative way of defining selectorbased filtering for scripts and/or servlets (declaration syntax is different but declaration and behavior of the system is always the same. IMHO we should go for the simplest mechanism first - which is the endresource being declared being part of a specific feature and carefully checking the lower level mechanisms for alter resource rendering. It still is better to have an easy and cheap solution that covers the easy cases but requires some engineering where more complex scenarios come into the game then forcing people to write custom code everywhere even for such common cases like disabling a Tab in a ui. Best regards Dominik On Mon, Jun 16, 2014 at 3:13 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß dominik.su...@gmail.com wrote: ...I fear it is not as easy since this mandates rendering engines to be able to perform that filtering (in other words - to be able to skip rendering based on the feature flag)... so IIUC you're looking at the alter resource rendering use case of [1] ? Note that even if the resource resolver hides rendering resources like scripts, I suspect you'll get in trouble as rendering scripts are cached. That's a good example of why I pushed for the SLING-3483 removal. ...This might not be that much work if applying features in the first place, but just think of a solution like AEM where a huge codebase should be featurized (e.g. a part should be deactivable due to licencing or some other criteria)... I sense a slightly more complex use case than [1] here...not sure if in-content feature flags are the right way to implement this. ... If I got the idea of featureflags right they should be at least invasive in code as possible, keeping the risk low that a deactivated feature by accident influences the rest of the system at all aka magic feature flags ;-) I agree that this looks nice, but as mentioned before I'm wary of multiple weird side effects like the caching thing mentioned above. We've seen those coming before SLING-3483, and so far no one has been able to reassure me that we're not opening a can of worms. ...From a consumers perspective I would like to be able to declare resources to be part of a feature (whitelisting) and probably to be removed for a feature (blacklisting - although this requires a logic resolving potential theoretical conflicts with a whitelist) by adding attributes... Assuming you want to work like this for scripts, how to you handle rendering servlets? -Bertrand [1] https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support P.S. no emotions about this on my side...I'm just not convinced so far, and wary of possible side effects. Best way to convince me is probably a prototype with sufficiently good tests that prove me wrong. -- Carsten
Re: [featureflags] Readding sling:features to resourceResolver
Hi, I would second the idea of Mike to implement featureflags on the technological base of a ResourceAccessGate but hiding it away. From a pure execution perspective it does exactly what is required. Regarding Performance I think this handling can be implemented in a cheap way while achiving the same via ACLs (as it was done for a long time) is much more expensive. It would probably be an option to define pathpatterns that won't be checked at all, since content created at runtime would most certainly not contain feature flags but there might be cases where you would like to define certain areas that need to be checked anyways. As for filters there need to be patterns to skip a check as early and cheap as possible. Comming back to the CRUD operations I do not really get the problem here, the problems are exactly the same as existing for ACL protected resources. We do even have an advantage here since we can utilize service users for dedicated visibility for processing and check existance of a resource via services without the need of a separate admin session to gracefully handle conflicts. Could someone please describe the scenario where a featureflag would be problematic in therms of create update or delete? I assume that the existing patterns to deal with the corresponding issues in ACL protected scenarios could be adapted and used as well. We could even decide to provide more information about why that fails when we decide that feature flag control is not to be handled as strict as ACLs (since no security feature). Best regards Dominik On Fri, Jun 13, 2014 at 12:10 AM, Carsten Ziegeler cziege...@apache.org wrote: In general I see two problems, one is performance and the other one is how to deal with CRUD operations wrt to feature flags on a resource. The latter point was the main trigger to pull this off. I think we should go back to talk about use cases. The number one use case I know in this area is displaying/hiding a button in a navigation - this can really easily be done in the navigation component itself when rendering: the resource has a specific property which is checked. If it contains a feature name this is compared with the active feature and then either this item is included or not. We could suggest a common name for the property and we could also come up with a filter utility class, so for code doing this it will be a short one liner. I don't want to add a heavy unclear concept into the resource resolver just for such a use case. Regards Carsten 2014-06-12 2:55 GMT-04:00 Mike Müller mike...@mysign.ch: Hi Just my 2 cents to it: Why not defining a featureflag-interface which is internally implemented with ResourceAccessGates. Personally I think ResourceAccessGates could do the job but I can follow the fear, that such a mechanism mixing up with a security mechanism could lead to bad design. So the solution could really be to wrap the ResourceAccessGates for the functionality of featureflags. Best regards mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Tuesday, June 10, 2014 2:53 PM To: dev Subject: [featureflags] Readding sling:features to resourceResolver Hi everyone, although I know this touches an area with a lot of emotions involved I wanted to reopen the discussion around Featureflags support for the resourceresolver. The last thing that happend was removing it for a release due to potential confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t Here are my arguments why I think it would be good to readd it to the resourceResolver (or any other mechanism being able to filter the resource tree: - Currently writing frontend that needs to adapt to featureflags requires adding custom code to check and filter the ui to be rendered. This leads to a lot of boilerplate code written over and over again with minor differences - Mechanisms relying on the Default Get Servlet JSON output would need to implement the filterlogic in clientside code. - ACL based solutions complicate the security setup for administrators because each feature would require a group (if toggling should be achived by membership instead of complex permissionrewriting) and could potentially impact performance of acl checks (not my domain so some specialists might be able to tell if those additional groups and memberships have impact on performance) The argument that developers might mistake feature flags with security is indicating that they don't read documentation (where potential security warnings should be written down in a prominent location) or do not care. But who does not care will not take care of proper ACLs anyways and assuming developers are using features without reading or respecting warnings in the documentation sounds a bit paranoid. I still think Resource Access Gate
Re: [featureflags] Readding sling:features to resourceResolver
Hi, On Fri, Jun 13, 2014 at 12:10 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I think we should go back to talk about use cases I agree, and keeping the list at https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support up to date might be a good starting point. -Bertrand
Re: [featureflags] Readding sling:features to resourceResolver
Hi, On Tue, Jun 10, 2014 at 2:53 PM, Dominik Süß dominik.su...@gmail.com wrote: -... Currently writing frontend that needs to adapt to featureflags requires adding custom code to check and filter the ui to be rendered. This leads to a lot of boilerplate code written over and over again with minor differences... Can't that be solved by a utility library? Maybe with minimal changes to the Sling core, but without baking feature flags into the core. -Bertrand
Re: [featureflags] Readding sling:features to resourceResolver
Hi Betrand, I fear it is not as easy since this mandates rendering engines to be able to perform that filtering (in other words - to be able to skip rendering based on the feature flag) or we would require developers to utilize filters which are way more intrusive then a Resource Access Gate and could potentially do much more harm. Additionally this code needs to be applied to each consumer. This might not be that much work if applying features in the first place, but just think of a solution like AEM where a huge codebase should be featurized (e.g. a part should be deactivable due to licencing or some other criteria): each and every part of the application depending on a contentstructure would need to learn this new concept instead of filtering the resourcetree in first place. If I got the idea of featureflags right they should be at least invasive in code as possible, keeping the risk low that a deactivated feature by accident influences the rest of the system at all. From a consumers perspective I would like to be able to declare resources to be part of a feature (whitelisting) and probably to be removed for a feature (blacklisting - although this requires a logic resolving potential theoretical conflicts with a whitelist) by adding attributes. This attribute check must be implemented in a cheap way (not much more then already done during resource resolution process). Best regards Dominik On Mon, Jun 16, 2014 at 9:58 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Tue, Jun 10, 2014 at 2:53 PM, Dominik Süß dominik.su...@gmail.com wrote: -... Currently writing frontend that needs to adapt to featureflags requires adding custom code to check and filter the ui to be rendered. This leads to a lot of boilerplate code written over and over again with minor differences... Can't that be solved by a utility library? Maybe with minimal changes to the Sling core, but without baking feature flags into the core. -Bertrand
Re: [featureflags] Readding sling:features to resourceResolver
Hi Dominik, On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß dominik.su...@gmail.com wrote: ...I fear it is not as easy since this mandates rendering engines to be able to perform that filtering (in other words - to be able to skip rendering based on the feature flag)... so IIUC you're looking at the alter resource rendering use case of [1] ? Note that even if the resource resolver hides rendering resources like scripts, I suspect you'll get in trouble as rendering scripts are cached. That's a good example of why I pushed for the SLING-3483 removal. ...This might not be that much work if applying features in the first place, but just think of a solution like AEM where a huge codebase should be featurized (e.g. a part should be deactivable due to licencing or some other criteria)... I sense a slightly more complex use case than [1] here...not sure if in-content feature flags are the right way to implement this. ... If I got the idea of featureflags right they should be at least invasive in code as possible, keeping the risk low that a deactivated feature by accident influences the rest of the system at all aka magic feature flags ;-) I agree that this looks nice, but as mentioned before I'm wary of multiple weird side effects like the caching thing mentioned above. We've seen those coming before SLING-3483, and so far no one has been able to reassure me that we're not opening a can of worms. ...From a consumers perspective I would like to be able to declare resources to be part of a feature (whitelisting) and probably to be removed for a feature (blacklisting - although this requires a logic resolving potential theoretical conflicts with a whitelist) by adding attributes... Assuming you want to work like this for scripts, how to you handle rendering servlets? -Bertrand [1] https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support P.S. no emotions about this on my side...I'm just not convinced so far, and wary of possible side effects. Best way to convince me is probably a prototype with sufficiently good tests that prove me wrong.
Re: [featureflags] Readding sling:features to resourceResolver
Hi Bertrand, I'm not really about altering resource rendering but enable disable resources for rendering, so I probably wouldn't decorate the scripts and servlets but the resources that define those resourceTypes. This is what we all have done a lot when hiding away frontend for endusers (at least I know nobody who didn't have to do that once in a while) via ACLs wherever the UI was composed from resources. I get the case where you would like to alter the Script/Servlet that handles a resourceType but as you mentioned this comes with quite some constraints and locations that would require some changes to work. To get this working we would definitively need some script metadata which could also be added as annotation to be able to distinct on servletresolution. I do not like the term magic feature flags since it implies there would happen something out of control for a developert. Declarative feature flags is matching what I'm thinking of - declaring something being part of a feature and having a unified behavior of the system to handle these for the specific cases just as we have a declarative way of defining selectorbased filtering for scripts and/or servlets (declaration syntax is different but declaration and behavior of the system is always the same. IMHO we should go for the simplest mechanism first - which is the endresource being declared being part of a specific feature and carefully checking the lower level mechanisms for alter resource rendering. It still is better to have an easy and cheap solution that covers the easy cases but requires some engineering where more complex scenarios come into the game then forcing people to write custom code everywhere even for such common cases like disabling a Tab in a ui. Best regards Dominik On Mon, Jun 16, 2014 at 3:13 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß dominik.su...@gmail.com wrote: ...I fear it is not as easy since this mandates rendering engines to be able to perform that filtering (in other words - to be able to skip rendering based on the feature flag)... so IIUC you're looking at the alter resource rendering use case of [1] ? Note that even if the resource resolver hides rendering resources like scripts, I suspect you'll get in trouble as rendering scripts are cached. That's a good example of why I pushed for the SLING-3483 removal. ...This might not be that much work if applying features in the first place, but just think of a solution like AEM where a huge codebase should be featurized (e.g. a part should be deactivable due to licencing or some other criteria)... I sense a slightly more complex use case than [1] here...not sure if in-content feature flags are the right way to implement this. ... If I got the idea of featureflags right they should be at least invasive in code as possible, keeping the risk low that a deactivated feature by accident influences the rest of the system at all aka magic feature flags ;-) I agree that this looks nice, but as mentioned before I'm wary of multiple weird side effects like the caching thing mentioned above. We've seen those coming before SLING-3483, and so far no one has been able to reassure me that we're not opening a can of worms. ...From a consumers perspective I would like to be able to declare resources to be part of a feature (whitelisting) and probably to be removed for a feature (blacklisting - although this requires a logic resolving potential theoretical conflicts with a whitelist) by adding attributes... Assuming you want to work like this for scripts, how to you handle rendering servlets? -Bertrand [1] https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support P.S. no emotions about this on my side...I'm just not convinced so far, and wary of possible side effects. Best way to convince me is probably a prototype with sufficiently good tests that prove me wrong.
RE: [featureflags] Readding sling:features to resourceResolver
Hi Just my 2 cents to it: Why not defining a featureflag-interface which is internally implemented with ResourceAccessGates. Personally I think ResourceAccessGates could do the job but I can follow the fear, that such a mechanism mixing up with a security mechanism could lead to bad design. So the solution could really be to wrap the ResourceAccessGates for the functionality of featureflags. Best regards mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Tuesday, June 10, 2014 2:53 PM To: dev Subject: [featureflags] Readding sling:features to resourceResolver Hi everyone, although I know this touches an area with a lot of emotions involved I wanted to reopen the discussion around Featureflags support for the resourceresolver. The last thing that happend was removing it for a release due to potential confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t Here are my arguments why I think it would be good to readd it to the resourceResolver (or any other mechanism being able to filter the resource tree: - Currently writing frontend that needs to adapt to featureflags requires adding custom code to check and filter the ui to be rendered. This leads to a lot of boilerplate code written over and over again with minor differences - Mechanisms relying on the Default Get Servlet JSON output would need to implement the filterlogic in clientside code. - ACL based solutions complicate the security setup for administrators because each feature would require a group (if toggling should be achived by membership instead of complex permissionrewriting) and could potentially impact performance of acl checks (not my domain so some specialists might be able to tell if those additional groups and memberships have impact on performance) The argument that developers might mistake feature flags with security is indicating that they don't read documentation (where potential security warnings should be written down in a prominent location) or do not care. But who does not care will not take care of proper ACLs anyways and assuming developers are using features without reading or respecting warnings in the documentation sounds a bit paranoid. I still think Resource Access Gate might be viable but some people convinced me that solving such a mechanism with a security mechanism would probably make distinction between security and business based access constraints (such as featureflags that constraint the access to a feature). Let's discuss this a bit so that everyone gets a clearer picture what issues where faced and why it was a better idea to remove this featureflag support and what would be the conditions under which no one would have an issue with readding a revamped featueflag support for the resource tree. Best regards Dominik
Re: [featureflags] Readding sling:features to resourceResolver
In general I see two problems, one is performance and the other one is how to deal with CRUD operations wrt to feature flags on a resource. The latter point was the main trigger to pull this off. I think we should go back to talk about use cases. The number one use case I know in this area is displaying/hiding a button in a navigation - this can really easily be done in the navigation component itself when rendering: the resource has a specific property which is checked. If it contains a feature name this is compared with the active feature and then either this item is included or not. We could suggest a common name for the property and we could also come up with a filter utility class, so for code doing this it will be a short one liner. I don't want to add a heavy unclear concept into the resource resolver just for such a use case. Regards Carsten 2014-06-12 2:55 GMT-04:00 Mike Müller mike...@mysign.ch: Hi Just my 2 cents to it: Why not defining a featureflag-interface which is internally implemented with ResourceAccessGates. Personally I think ResourceAccessGates could do the job but I can follow the fear, that such a mechanism mixing up with a security mechanism could lead to bad design. So the solution could really be to wrap the ResourceAccessGates for the functionality of featureflags. Best regards mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Tuesday, June 10, 2014 2:53 PM To: dev Subject: [featureflags] Readding sling:features to resourceResolver Hi everyone, although I know this touches an area with a lot of emotions involved I wanted to reopen the discussion around Featureflags support for the resourceresolver. The last thing that happend was removing it for a release due to potential confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t Here are my arguments why I think it would be good to readd it to the resourceResolver (or any other mechanism being able to filter the resource tree: - Currently writing frontend that needs to adapt to featureflags requires adding custom code to check and filter the ui to be rendered. This leads to a lot of boilerplate code written over and over again with minor differences - Mechanisms relying on the Default Get Servlet JSON output would need to implement the filterlogic in clientside code. - ACL based solutions complicate the security setup for administrators because each feature would require a group (if toggling should be achived by membership instead of complex permissionrewriting) and could potentially impact performance of acl checks (not my domain so some specialists might be able to tell if those additional groups and memberships have impact on performance) The argument that developers might mistake feature flags with security is indicating that they don't read documentation (where potential security warnings should be written down in a prominent location) or do not care. But who does not care will not take care of proper ACLs anyways and assuming developers are using features without reading or respecting warnings in the documentation sounds a bit paranoid. I still think Resource Access Gate might be viable but some people convinced me that solving such a mechanism with a security mechanism would probably make distinction between security and business based access constraints (such as featureflags that constraint the access to a feature). Let's discuss this a bit so that everyone gets a clearer picture what issues where faced and why it was a better idea to remove this featureflag support and what would be the conditions under which no one would have an issue with readding a revamped featueflag support for the resource tree. Best regards Dominik -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[featureflags] Readding sling:features to resourceResolver
Hi everyone, although I know this touches an area with a lot of emotions involved I wanted to reopen the discussion around Featureflags support for the resourceresolver. The last thing that happend was removing it for a release due to potential confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t Here are my arguments why I think it would be good to readd it to the resourceResolver (or any other mechanism being able to filter the resource tree: - Currently writing frontend that needs to adapt to featureflags requires adding custom code to check and filter the ui to be rendered. This leads to a lot of boilerplate code written over and over again with minor differences - Mechanisms relying on the Default Get Servlet JSON output would need to implement the filterlogic in clientside code. - ACL based solutions complicate the security setup for administrators because each feature would require a group (if toggling should be achived by membership instead of complex permissionrewriting) and could potentially impact performance of acl checks (not my domain so some specialists might be able to tell if those additional groups and memberships have impact on performance) The argument that developers might mistake feature flags with security is indicating that they don't read documentation (where potential security warnings should be written down in a prominent location) or do not care. But who does not care will not take care of proper ACLs anyways and assuming developers are using features without reading or respecting warnings in the documentation sounds a bit paranoid. I still think Resource Access Gate might be viable but some people convinced me that solving such a mechanism with a security mechanism would probably make distinction between security and business based access constraints (such as featureflags that constraint the access to a feature). Let's discuss this a bit so that everyone gets a clearer picture what issues where faced and why it was a better idea to remove this featureflag support and what would be the conditions under which no one would have an issue with readding a revamped featueflag support for the resource tree. Best regards Dominik
