You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2013/11/12 16:52:46 UTC
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
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 13.11.2013 um 23:12 schrieb Felix Meschberger <fm...@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 <bd...@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
Posted by Felix Meschberger <fm...@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).
Regards
Felix
—
Felix Meschberger | Principal Scientist | Adobe
Am 13.11.2013 um 02:52 schrieb Bertrand Delacretaz <bd...@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
Posted by Robert Munteanu <ro...@lmn.ro>.
On Wed, Nov 13, 2013 at 1:06 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Robert,
>
> On Tue, Nov 12, 2013 at 5:38 PM, Robert Munteanu <ro...@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Robert,
On Tue, Nov 12, 2013 at 5:38 PM, Robert Munteanu <ro...@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
Posted by Robert Munteanu <ro...@lmn.ro>.
Hi Bertrand,
On Tue, Nov 12, 2013 at 5:52 PM, Bertrand Delacretaz
<bd...@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
RE: FYI: feature flags prototype
Posted by Mike Müller <mi...@mysign.ch>.
> On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger
> <fm...@adobe.com>wrote:
>
> > 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
Posted by Dominik Süß <do...@gmail.com>.
Hi Felix,
see my comments inline.
Best regards
Dominik
On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger <fm...@adobe.com>wrote:
> 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 <mi...@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.suess@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 <js...@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 <fmeschbe@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üß <do...@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 <rr...@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 test&target 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 <
> >>>>>>> bdelacretaz@apache.org> wrote:
> >>>>>>>
> >>>>>>> Hi Dominik,
> >>>>>>>>
> >>>>>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <
> >>> dominik.suess@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
Posted by Felix Meschberger <fm...@adobe.com>.
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 <mi...@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.suess@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 <js...@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 <fm...@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üß <do...@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 <rr...@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 test&target 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 <
>>>>>>> bdelacretaz@apache.org> wrote:
>>>>>>>
>>>>>>> Hi Dominik,
>>>>>>>>
>>>>>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <
>>> dominik.suess@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
Posted by Dominik Süß <do...@gmail.com>.
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 <bdelacretaz@apache.org
> wrote:
> On Fri, Nov 15, 2013 at 7:51 AM, Dominik Süß <do...@gmail.com>
> wrote:
> > Am 14.11.2013 23:11 schrieb "Alexander Klimetschek" <aklimets@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 15, 2013 at 7:51 AM, Dominik Süß <do...@gmail.com> wrote:
> Am 14.11.2013 23:11 schrieb "Alexander Klimetschek" <ak...@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
Posted by Dominik Süß <do...@gmail.com>.
Am 14.11.2013 23:11 schrieb "Alexander Klimetschek" <ak...@adobe.com>:
>
> On 14.11.2013, at 13:55, Dominik Süß <do...@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
Re: FYI: feature flags prototype
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 14.11.2013, at 13:55, Dominik Süß <do...@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
Posted by Ruben Reusser <rr...@headwire.com>.
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
> <ak...@adobe.com>wrote:
>
>> On 14.11.2013, at 05:11, Dominik Süß <do...@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: [OT] Feature flag influence on Resource access (Was: FYI:
feature flags prototype)
Posted by Mike Müller <mi...@mysign.ch>.
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:bdelacretaz@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 <fm...@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)
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 12.12.2013, at 19:40, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ak...@adobe.com>
> On 11.12.2013, at 19:10, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI:
feature flags prototype)
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 11.12.2013, at 19:10, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ak...@adobe.com>
> From: Felix Meschberger <fm...@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
cziegeler@apache.org
RE: [OT] Feature flag influence on Resource access (Was: FYI:
feature flags prototype)
Posted by Alexander Klimetschek <ak...@adobe.com>.
From: Felix Meschberger <fm...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
:) 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 <fm...@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 <cz...@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 <bd...@apache.org>
> >
> >> On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler <cziegeler@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
> > cziegeler@apache.org
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Dec 11, 2013 at 10:00 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 2013/12/11 Bertrand Delacretaz <bd...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/12/11 Bertrand Delacretaz <bd...@apache.org>
> Hi,
>
> On Wed, Dec 11, 2013 at 9:34 AM, Felix Meschberger <fm...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 11, 2013 at 9:34 AM, Felix Meschberger <fm...@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)
Posted by Felix Meschberger <fm...@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 <cz...@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 <bd...@apache.org>
>
>> On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler <cz...@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
> cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Carsten Ziegeler <cz...@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 <bd...@apache.org>
> On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler <cz...@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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <fm...@adobe.com>
> Hi
>
> Am 10.12.2013 um 12:04 schrieb Bertrand Delacretaz <bdelacretaz@apache.org
> >:
>
> > On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI:
feature flags prototype)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 10.12.2013 um 12:04 schrieb Bertrand Delacretaz <bd...@apache.org>:
> On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler <cz...@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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <bd...@apache.org>
> Hi,
>
> On Mon, Dec 9, 2013 at 11:01 PM, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Dec 9, 2013 at 11:01 PM, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
Good idea - do we have a wiki page where we collect real use cases for
feature flags?
Carsten
2013/12/10 Bertrand Delacretaz <bd...@apache.org>
> Hi,
>
> On Sun, Dec 8, 2013 at 6:04 AM, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sun, Dec 8, 2013 at 6:04 AM, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <rr...@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
>> <ak...@adobe.com> wrote:
>>
>>> On 06.12.2013, at 08:08, Felix Meschberger <fm...@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
cziegeler@apache.org
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Ruben Reusser <rr...@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
> <ak...@adobe.com> wrote:
>> On 06.12.2013, at 08:08, Felix Meschberger <fm...@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)
Posted by Justin Edelson <ju...@justinedelson.com>.
On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> On 06.12.2013, at 08:08, Felix Meschberger <fm...@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)
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 06.12.2013, at 08:08, Felix Meschberger <fm...@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)
Posted by Felix Meschberger <fm...@adobe.com>.
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 <bd...@apache.org>:
> Hi,
>
> On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger <fm...@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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger <fm...@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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 15, 2013 at 2:23 PM, Felix Meschberger <fm...@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)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 16.11.2013 um 00:11 schrieb Amit.. Gupta. <am...@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, Callable<T>) 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:fmeschbe@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 -> Iterator<Resource>
> * getChildren -> Iterable<Resource>
> * queryResources -> Iterator<Map<String,Object>>
> * findResources -> Iterator<Resource>
> 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. Iterator<Resource> 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: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Dominik Süß <do...@gmail.com>.
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. <am...@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.suess@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. <am...@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:fmeschbe@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 -> Iterator<Resource>
> > * getChildren -> Iterable<Resource>
> > * queryResources -> Iterator<Map<String,Object>>
> > * findResources -> Iterator<Resource>
> > 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.
> > Iterator<Resource> 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: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Dominik Süß <do...@gmail.com>.
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 <hs...@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" <fi...@gbiv.com> wrote:
>
> > On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote:
> >> On 15.11.2013, at 07:13, Amit.. Gupta. <am...@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: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Posted by Henry Saginor <hs...@gmail.com>.
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" <fi...@gbiv.com> wrote:
> On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote:
>> On 15.11.2013, at 07:13, Amit.. Gupta. <am...@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: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote:
> On 15.11.2013, at 07:13, Amit.. Gupta. <am...@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: [OT] Feature flag influence on Resource access (Was: FYI:
feature flags prototype)
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 15.11.2013, at 07:13, Amit.. Gupta. <am...@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)
Posted by "Amit.. Gupta." <am...@adobe.com>.
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.suess@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. <am...@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:fmeschbe@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 -> Iterator<Resource>
> * getChildren -> Iterable<Resource>
> * queryResources -> Iterator<Map<String,Object>>
> * findResources -> Iterator<Resource>
> 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.
> Iterator<Resource> 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: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Dominik Süß <do...@gmail.com>.
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. <am...@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:fmeschbe@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 -> Iterator<Resource>
> * getChildren -> Iterable<Resource>
> * queryResources -> Iterator<Map<String,Object>>
> * findResources -> Iterator<Resource>
> 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.
> Iterator<Resource> 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: [OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Julian Sedding <js...@gmail.com>.
> 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. <am...@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:fmeschbe@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 -> Iterator<Resource>
> * getChildren -> Iterable<Resource>
> * queryResources -> Iterator<Map<String,Object>>
> * findResources -> Iterator<Resource>
> 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. Iterator<Resource> 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: [OT] Feature flag influence on Resource access (Was: FYI:
feature flags prototype)
Posted by "Amit.. Gupta." <am...@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. 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:fmeschbe@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 -> Iterator<Resource>
* getChildren -> Iterable<Resource>
* queryResources -> Iterator<Map<String,Object>>
* findResources -> Iterator<Resource>
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. Iterator<Resource> 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
[OT] Feature flag influence on Resource access (Was: FYI: feature
flags prototype)
Posted by Felix Meschberger <fm...@adobe.com>.
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 -> Iterator<Resource>
* getChildren -> Iterable<Resource>
* queryResources -> Iterator<Map<String,Object>>
* findResources -> Iterator<Resource>
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. Iterator<Resource> 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
Posted by Dominik Süß <do...@gmail.com>.
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
<ak...@adobe.com>wrote:
> On 14.11.2013, at 05:11, Dominik Süß <do...@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
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 14.11.2013, at 05:11, Dominik Süß <do...@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 14, 2013 at 2:37 PM, Felix Meschberger <fm...@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
Posted by Felix Meschberger <fm...@adobe.com>.
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üß <do...@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 <bdelacretaz@apache.org
>> wrote:
>
>> On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller <mi...@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
Posted by Dominik Süß <do...@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 <bdelacretaz@apache.org
> wrote:
> On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller <mi...@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller <mi...@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
Posted by Mike Müller <mi...@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.suess@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 <js...@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 <fm...@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üß <do...@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 <rr...@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 test&target 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 <
> > >>>> bdelacretaz@apache.org> wrote:
> > >>>>
> > >>>> Hi Dominik,
> > >>>>>
> > >>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <
> > dominik.suess@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
Posted by Dominik Süß <do...@gmail.com>.
+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 <js...@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 <fm...@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üß <do...@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 <rr...@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 test&target 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 <
> >>>> bdelacretaz@apache.org> wrote:
> >>>>
> >>>> Hi Dominik,
> >>>>>
> >>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <
> dominik.suess@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding <js...@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
Posted by Julian Sedding <js...@gmail.com>.
> 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 <fm...@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üß <do...@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 <rr...@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 test&target 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 <
>>>> bdelacretaz@apache.org> wrote:
>>>>
>>>> Hi Dominik,
>>>>>
>>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <do...@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
Posted by Felix Meschberger <fm...@adobe.com>.
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üß <do...@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 <rr...@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 test&target 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 <
>>> bdelacretaz@apache.org> wrote:
>>>
>>> Hi Dominik,
>>>>
>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <do...@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
Posted by Dominik Süß <do...@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 <rr...@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 test&target 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 <
>> bdelacretaz@apache.org> wrote:
>>
>> Hi Dominik,
>>>
>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <do...@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
Posted by Ruben Reusser <rr...@headwire.com>.
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 test&target 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 <
> bdelacretaz@apache.org> wrote:
>
>> Hi Dominik,
>>
>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <do...@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
Posted by Dominik Süß <do...@gmail.com>.
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 <
bdelacretaz@apache.org> wrote:
> Hi Dominik,
>
> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <do...@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Dominik,
On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <do...@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
Posted by Dominik Süß <do...@gmail.com>.
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 <bdelacretaz@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
Posted by Felix Meschberger <fm...@adobe.com>.
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 <bd...@apache.org>:
> Hi Tommaso,
>
> On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili
> <to...@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Tommaso,
On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili
<to...@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
Posted by Tommaso Teofili <to...@gmail.com>.
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 <bd...@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
>