You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2014/01/20 04:19:24 UTC
[FeatureFlags] Handling of sling:features property
If the sling:features property contains a single string value, this
resource is only visible if the feature is enabled. This is pretty straight
forward.
It seems we have use cases, like A-B testing where you want to hide a
resource if a feature is enabled, so A is enabled and B is hidden if the
feature is active, and A is hidden but B is active if the feature is not
active. We can easily implement this with negating the value, like
!featureX as a single string property value.
Now, how do we treat a multi value for sling:features, like ["featureA",
"featureB"]? Is this resource visible if both features are active (AND) or
if at least one of the two is active (OR)?
And it gets very interesting if at least one value is negated, like
["featureA", "!featureB", "featureC"] ?
And while we're at it, is it possible to hide a hole tree? So if I have a
content tree with many child nodes at /foo and add a sling:features
property to the root node foo, is the whole sub tree hidden if the feature
is not active?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Felix Meschberger <fm...@adobe.com>.
+1 to both.
Regards
Felix
Am 22.01.2014 um 16:34 schrieb Carsten Ziegeler <cz...@apache.org>:
> Great, I'm fine with this - I just want to make sure that we're all on the
> same page :)
>
> Carsten
>
>
> 2014/1/22 Bertrand Delacretaz <bd...@apache.org>
>
>> On Wed, Jan 22, 2014 at 4:05 PM, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>>> ...Final question, is this still an OR then? So if you have ["-A", "-B"]
>> or
>>> ["-A", "B"] what does it mean?...
>>
>> I think we agree on OR so to me
>>
>> [-A, -B] means "this resource is visible if feature A is disabled OR
>> feature B is disabled.
>>
>> [-A, B] means "this resource is visible if feature A is disabled OR
>> feature B is enabled.
>>
>> And people can implement their own composite Features if they need
>> more complex combinations.
>>
>> -Bertrand
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Carsten Ziegeler <cz...@apache.org>.
Great, I'm fine with this - I just want to make sure that we're all on the
same page :)
Carsten
2014/1/22 Bertrand Delacretaz <bd...@apache.org>
> On Wed, Jan 22, 2014 at 4:05 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > ...Final question, is this still an OR then? So if you have ["-A", "-B"]
> or
> > ["-A", "B"] what does it mean?...
>
> I think we agree on OR so to me
>
> [-A, -B] means "this resource is visible if feature A is disabled OR
> feature B is disabled.
>
> [-A, B] means "this resource is visible if feature A is disabled OR
> feature B is enabled.
>
> And people can implement their own composite Features if they need
> more complex combinations.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jan 22, 2014 at 4:05 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...Final question, is this still an OR then? So if you have ["-A", "-B"] or
> ["-A", "B"] what does it mean?...
I think we agree on OR so to me
[-A, -B] means "this resource is visible if feature A is disabled OR
feature B is disabled.
[-A, B] means "this resource is visible if feature A is disabled OR
feature B is enabled.
And people can implement their own composite Features if they need
more complex combinations.
-Bertrand
Re: [FeatureFlags] Handling of sling:features property
Posted by Carsten Ziegeler <cz...@apache.org>.
Great, thanks, yeah I'm fine with "-"
Final question, is this still an OR then? So if you have ["-A", "-B"] or
["-A", "B"] what does it mean?
Carsten
2014/1/22 Felix Meschberger <fm...@adobe.com>
> Hi
>
> I am ok, this is easy to implement and I am fine with using "-" as the
> indicator — we also use that prefix to indicate URLs which don't need
> authentication (AuthConstants.AUTH_REQUIREMENTS).
>
> Regards
> Felix
>
> Am 22.01.2014 um 15:04 schrieb Carsten Ziegeler <cz...@apache.org>:
>
> > @Felix, wdyt?
> >
> > Carsten
> >
> >
> > 2014/1/21 Bertrand Delacretaz <bd...@apache.org>
> >
> >> Hi,
> >>
> >> On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler <cziegeler@apache.org
> >
> >> wrote:
> >>> ...Can we get some consensus, whether we need to specify that a
> resource
> >> is
> >>> hidden if a feature is enabled?...
> >>
> >> We need this to implement the "Alternate between resources based on
> >> feature flags" use case described at
> >>
> >>
> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
> >>
> >>>
> >>> The use case I heard of, is that e.g. a button/link(navigation entry is
> >>> switched depending whether the feature is available. If it's available
> >>> button A is rendered, if not button B - this could be easily done with
> >> two
> >>> resources, one enabled for the feature and the other one disabled....
> >>
> >> That's what the above use case describes.
> >>
> >> -Bertrand
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
I am ok, this is easy to implement and I am fine with using "-" as the indicator — we also use that prefix to indicate URLs which don't need authentication (AuthConstants.AUTH_REQUIREMENTS).
Regards
Felix
Am 22.01.2014 um 15:04 schrieb Carsten Ziegeler <cz...@apache.org>:
> @Felix, wdyt?
>
> Carsten
>
>
> 2014/1/21 Bertrand Delacretaz <bd...@apache.org>
>
>> Hi,
>>
>> On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>>> ...Can we get some consensus, whether we need to specify that a resource
>> is
>>> hidden if a feature is enabled?...
>>
>> We need this to implement the "Alternate between resources based on
>> feature flags" use case described at
>>
>> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
>>
>>>
>>> The use case I heard of, is that e.g. a button/link(navigation entry is
>>> switched depending whether the feature is available. If it's available
>>> button A is rendered, if not button B - this could be easily done with
>> two
>>> resources, one enabled for the feature and the other one disabled....
>>
>> That's what the above use case describes.
>>
>> -Bertrand
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Carsten Ziegeler <cz...@apache.org>.
@Felix, wdyt?
Carsten
2014/1/21 Bertrand Delacretaz <bd...@apache.org>
> Hi,
>
> On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > ...Can we get some consensus, whether we need to specify that a resource
> is
> > hidden if a feature is enabled?...
>
> We need this to implement the "Alternate between resources based on
> feature flags" use case described at
>
> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
>
> >
> > The use case I heard of, is that e.g. a button/link(navigation entry is
> > switched depending whether the feature is available. If it's available
> > button A is rendered, if not button B - this could be easily done with
> two
> > resources, one enabled for the feature and the other one disabled....
>
> That's what the above use case describes.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Jan 21, 2014 at 2:38 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...Can we get some consensus, whether we need to specify that a resource is
> hidden if a feature is enabled?...
We need this to implement the "Alternate between resources based on
feature flags" use case described at
https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
>
> The use case I heard of, is that e.g. a button/link(navigation entry is
> switched depending whether the feature is available. If it's available
> button A is rendered, if not button B - this could be easily done with two
> resources, one enabled for the feature and the other one disabled....
That's what the above use case describes.
-Bertrand
Re: [FeatureFlags] Handling of sling:features property
Posted by Carsten Ziegeler <cz...@apache.org>.
Can we get some consensus, whether we need to specify that a resource is
hidden if a feature is enabled?
The use case I heard of, is that e.g. a button/link(navigation entry is
switched depending whether the feature is available. If it's available
button A is rendered, if not button B - this could be easily done with two
resources, one enabled for the feature and the other one disabled.
But if there are other, easier ways of doing this, I'm fine as well
Thanks
Carsten
2014/1/20 Carsten Ziegeler <cz...@apache.org>
> I'm fine with using OR and not going up the hierarchy to see whether a
> parent is hidden.
>
> Carsten
>
>
> 2014/1/20 Bertrand Delacretaz <bd...@apache.org>
>
>> Hi,
>>
>> On Mon, Jan 20, 2014 at 9:35 AM, Felix Meschberger <fm...@adobe.com>
>> wrote:
>> > Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <cz...@apache.org>:
>> >>... It seems we have use cases, like A-B testing where you want to hide
>> a
>> >> resource if a feature is enabled..
>> >> ...We can easily implement this with negating the value, like
>> >> !featureX as a single string property value...
>>
>> Agreed, but isn't -featureX more readable? We are using - already to
>> negate tags when selecting health checks for example, not sure if we
>> are already using ! in other places at the user level.
>>
>> > ...So to do A-B testing in this case your resources will have to be one
>> in front of
>> > another in the virtual candidate list and the feature flag on the first
>> indicating whether
>> > to accept it or not....
>>
>> And how do you "put a resource in front of the other" ? Doesn't seem
>> convenient to me, the -featureX syntax is simple and unsurprising.
>>
>> >
>> > ...I think we should come up with really concrete requirements and
>> implementation proposals
>> > to be able to discuss this further...
>>
>> We do have use cases at
>>
>> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
>> ,
>> this one is "alternate between resources based on feature flags".
>>
>> As for the implementation, adding support for negated feature names in
>> ResourceResolverContext.applyFeatures() in your current whiteboard
>> prototype looks trivial.
>>
>> >> Now, how do we treat a multi value for sling:features, like
>> ["featureA",
>> >> "featureB"]? Is this resource visible if both features are active
>> (AND) or
>> >> if at least one of the two is active (OR)?...
>>
>> Like Felix I think using OR here is the simplest, if someone needs AND
>> they can always implement a Feature that's a composite of others.
>>
>> If you then have sling:features = "A, -B, C" the resource is visible
>> if feature A is enabled OR feature B is disabled OR feature C is
>> enabled, that's clear IMO.
>>
>> I also agree with leaving feature tree inheritance for later, that
>> shouldn't have impact on APIs, it's only an implementation change.
>>
>> -Bertrand
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Carsten Ziegeler <cz...@apache.org>.
I'm fine with using OR and not going up the hierarchy to see whether a
parent is hidden.
Carsten
2014/1/20 Bertrand Delacretaz <bd...@apache.org>
> Hi,
>
> On Mon, Jan 20, 2014 at 9:35 AM, Felix Meschberger <fm...@adobe.com>
> wrote:
> > Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <cz...@apache.org>:
> >>... It seems we have use cases, like A-B testing where you want to hide a
> >> resource if a feature is enabled..
> >> ...We can easily implement this with negating the value, like
> >> !featureX as a single string property value...
>
> Agreed, but isn't -featureX more readable? We are using - already to
> negate tags when selecting health checks for example, not sure if we
> are already using ! in other places at the user level.
>
> > ...So to do A-B testing in this case your resources will have to be one
> in front of
> > another in the virtual candidate list and the feature flag on the first
> indicating whether
> > to accept it or not....
>
> And how do you "put a resource in front of the other" ? Doesn't seem
> convenient to me, the -featureX syntax is simple and unsurprising.
>
> >
> > ...I think we should come up with really concrete requirements and
> implementation proposals
> > to be able to discuss this further...
>
> We do have use cases at
>
> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
> ,
> this one is "alternate between resources based on feature flags".
>
> As for the implementation, adding support for negated feature names in
> ResourceResolverContext.applyFeatures() in your current whiteboard
> prototype looks trivial.
>
> >> Now, how do we treat a multi value for sling:features, like ["featureA",
> >> "featureB"]? Is this resource visible if both features are active (AND)
> or
> >> if at least one of the two is active (OR)?...
>
> Like Felix I think using OR here is the simplest, if someone needs AND
> they can always implement a Feature that's a composite of others.
>
> If you then have sling:features = "A, -B, C" the resource is visible
> if feature A is enabled OR feature B is disabled OR feature C is
> enabled, that's clear IMO.
>
> I also agree with leaving feature tree inheritance for later, that
> shouldn't have impact on APIs, it's only an implementation change.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [FeatureFlags] Handling of sling:features property
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Jan 20, 2014 at 9:35 AM, Felix Meschberger <fm...@adobe.com> wrote:
> Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <cz...@apache.org>:
>>... It seems we have use cases, like A-B testing where you want to hide a
>> resource if a feature is enabled..
>> ...We can easily implement this with negating the value, like
>> !featureX as a single string property value...
Agreed, but isn't -featureX more readable? We are using - already to
negate tags when selecting health checks for example, not sure if we
are already using ! in other places at the user level.
> ...So to do A-B testing in this case your resources will have to be one in front of
> another in the virtual candidate list and the feature flag on the first indicating whether
> to accept it or not....
And how do you "put a resource in front of the other" ? Doesn't seem
convenient to me, the -featureX syntax is simple and unsurprising.
>
> ...I think we should come up with really concrete requirements and implementation proposals
> to be able to discuss this further...
We do have use cases at
https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support,
this one is "alternate between resources based on feature flags".
As for the implementation, adding support for negated feature names in
ResourceResolverContext.applyFeatures() in your current whiteboard
prototype looks trivial.
>> Now, how do we treat a multi value for sling:features, like ["featureA",
>> "featureB"]? Is this resource visible if both features are active (AND) or
>> if at least one of the two is active (OR)?...
Like Felix I think using OR here is the simplest, if someone needs AND
they can always implement a Feature that's a composite of others.
If you then have sling:features = "A, -B, C" the resource is visible
if feature A is enabled OR feature B is disabled OR feature C is
enabled, that's clear IMO.
I also agree with leaving feature tree inheritance for later, that
shouldn't have impact on APIs, it's only an implementation change.
-Bertrand
Re: [FeatureFlags] Handling of sling:features property
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <cz...@apache.org>:
> If the sling:features property contains a single string value, this
> resource is only visible if the feature is enabled. This is pretty straight
> forward.
Yes
> It seems we have use cases, like A-B testing where you want to hide a
> resource if a feature is enabled, so A is enabled and B is hidden if the
> feature is active, and A is hidden but B is active if the feature is not
> active. We can easily implement this with negating the value, like
> !featureX as a single string property value.
I do not really understand …
With feature flag support in the resource resolver we essentially control whether a candidate resource is selected to be resolved or got. The first resource found that can be used is returned. "Can be used" means, it is readable and either has no feature flag or the named feature is enabled.
So to do A-B testing in this case your resources will have to be one in front of another in the virtual candidate list and the feature flag on the first indicating whether to accept it or not.
I think we should come up with really concrete requirements and implementation proposals to be able to discuss this further.
For now, I would prefer to not go down this route and keep it simple.
>
> Now, how do we treat a multi value for sling:features, like ["featureA",
> "featureB"]? Is this resource visible if both features are active (AND) or
> if at least one of the two is active (OR)?
> And it gets very interesting if at least one value is negated, like
> ["featureA", "!featureB", "featureC"] ?
Well, my current implementation says: a resource is visible if at least one of the named features is enabled. In this sense it is featureA OR featureB OR featureC. There is no negation and no AND.
I would think that more complicated logic to select resources should actually involve real scripted (or servlet) logic where two (A-B) or more (A-B-C-…) resources are known and can be chosen and then <sling:include>-ed
>
> And while we're at it, is it possible to hide a hole tree? So if I have a
> content tree with many child nodes at /foo and add a sling:features
> property to the root node foo, is the whole sub tree hidden if the feature
> is not active?
It is currently hidding if you drill down the tree going from get(/foo) to listChildren. A descendant resource /foo/some/where/inside is not hidden. As such the feature flag does not currently have a hierarchic consequence.
I could think that we might to want it to have a hierarchic consequence with more consequences on performance on asking on how to "remove" the feature flag down the tree again. Maybe for now, don't do this.
Regards
Felix
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org