[
https://issues.apache.org/jira/browse/SLING-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820193#comment-13820193
]
Bertrand Delacretaz edited comment on SLING-3148 at 11/12/13 3:38 PM:
----------------------------------------------------------------------
To be useful I think feature flags need to be more dynamic than just
enabling/disabling OSGi services or bundles. Being able to enable a feature for
just specific requests, user groups or for a percentage of all requests is
where this really shines.
The slides at [1] give a good overview IMO (thanks [~teofili]!}, based on that
we can imagine feature flags based on various things like run mode, request,
user, group, resource, random percentage, opt-in cookie etc.
I'm not sure if we need an external library for that, creating our own is quite
simple and can fully take advantage of the Sling environment. I have created a
minimal prototype at [2] that has 3 example feature flags providers based on
resource paths, random numbers and a request header. A demo servlet dumps the
feature flag values, which depend on the current request, in JSON:
{code}
$ curl -HX-sling-feature:foo http://localhost:8080/tmp/foo.featureflags.json
{
"featureFlags": {
"request.header.feature": true,
"random.feature": false,
"resource.path.feature": true
}
}
$ curl http://localhost:8080/apps.featureflags.json
{
"featureFlags": {
"request.header.feature": false,
"random.feature": true,
"resource.path.feature": false
}
}
{code}
The implementation is very simple, if we agree on the need we could move it
under contrib and make the examples more useful.
[1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf
[2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
was (Author: bdelacretaz):
To be useful I think feature flags need to be more dynamic than just
enabling/disabling OSGi services or bundles.
The slides at [1] give a good overview IMO (thanks [~teofili]!}, based on that
we can imagine feature flags based on various things like run mode, request,
user, group, resource, random percentage, opt-in cookie etc.
I'm not sure if we need an external library for that, creating our own is quite
simple and can fully take advantage of the Sling environment. I have created a
minimal prototype at [2] that has 3 example feature flags providers based on
resource paths, random numbers and a request header. A demo servlet dumps the
feature flag values, which depend on the current request, in JSON:
{code}
$ curl -HX-sling-feature:foo http://localhost:8080/tmp/foo.featureflags.json
{
"featureFlags": {
"request.header.feature": true,
"random.feature": false,
"resource.path.feature": true
}
}
$ curl http://localhost:8080/apps.featureflags.json
{
"featureFlags": {
"request.header.feature": false,
"random.feature": true,
"resource.path.feature": false
}
}
{code}
The implementation is very simple, if we agree on the need we could move it
under contrib and make the examples more useful.
[1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf
[2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
> Implement support for Feature Flags/Toggles in Sling
> ----------------------------------------------------
>
> Key: SLING-3148
> URL: https://issues.apache.org/jira/browse/SLING-3148
> Project: Sling
> Issue Type: New Feature
> Components: General
> Reporter: Henry Saginor
> Priority: Minor
>
> It would be nice if sling provide support for feature flags (also called
> toggles) pattern [1].
> I am thinking the implementation could provide the following.
> 1) Integrate an existing framework such as togglz [2] or implement something
> similar with UI/Configuration to toggle features.
> 2) Create a jcr property (sling:Feature) which can be added to resource type
> nodes. Then some conditional logic in <sling:include>, and get and post
> servlets determines if the resource should be rendered if its resource type
> contains such property.
> [1] http://en.wikipedia.org/wiki/Feature_toggle
> [2] http://www.togglz.org/
--
This message was sent by Atlassian JIRA
(v6.1#6144)
