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 <[email protected]>: > 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:[email protected]] > > 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 [email protected]
