[featureflags] Readding sling:features to resourceResolver

[Dominik Süß <do...@gmail.com>]

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

[Carsten Ziegeler <cz...@apache.org>]

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üß <do...@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 <
> bdelacretaz@apache.org
> > wrote:
>
> > Hi Dominik,
> >
> > On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß <do...@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 Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [featureflags] Readding sling:features to resourceResolver

[Dominik Süß <do...@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 <bdelacretaz@apache.org
> wrote:

> Hi Dominik,
>
> On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß <do...@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

[Bertrand Delacretaz <bd...@apache.org>]

Hi Dominik,

On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß <do...@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

[Dominik Süß <do...@gmail.com>]

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 <bdelacretaz@apache.org
> wrote:

> Hi,
>
> On Tue, Jun 10, 2014 at 2:53 PM, Dominik Süß <do...@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

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Tue, Jun 10, 2014 at 2:53 PM, Dominik Süß <do...@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

[Dominik Süß <do...@gmail.com>]

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 <cz...@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 <mi...@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.suess@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
> cziegeler@apache.org
>

Re: [featureflags] Readding sling:features to resourceResolver

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Fri, Jun 13, 2014 at 12:10 AM, Carsten Ziegeler <cz...@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

[Carsten Ziegeler <cz...@apache.org>]

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 <mi...@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.suess@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
cziegeler@apache.org

RE: [featureflags] Readding sling:features to resourceResolver

[Mike Müller <mi...@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.suess@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