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