Hi It took me a bit longer and caused me a few more changes to the FeatureFlags stuff ….
So instead of immediately merging back to trunk, lets have another round of discussions. The most important changes (off the top of my mind): * Support HttpServletRequest instead of requiring SlingHttpServletRequest for the ClientContext and ExecutionContext. This allows using this functionality outside of Sling (I hope) * Add Web Console listing known features * Add support for org.apache.sling.featureflags.Feature factory configuration (static configuration can be overwritten with "feature" request parameter) * additional services registered through FeatureManager, which itself is not a service any longer I also added a crude page to the staging at [1] WDYT ? Regards Felix [1] http://sling.staging.apache.org/documentation/the-sling-engine/featureflags.html Am 17.01.2014 um 16:32 schrieb Felix Meschberger <fmesc...@adobe.com>: > Hi > > As I repeatedly said, I think the Feature Flags support should be implemented > without the ResourceAccessGate mechanism because it is not an access control > thing but a purely operational visibility thing. Also as opposed to access > control, feature flag enabled can and should be controllable by a consumer of > the API; for example by passing a request parameter on the request. > > Based on the existing code, I have created a prototype in my whiteboard at > [1]: > > * On a per-resource level feature flags are set as sling:feature properties > of type String or String[] > * Flags are checked during resource resolution in the > ProviderHandler.getReadableResource method > * Feature services can implement ResourceDecorator such that they can > decorate a resource in case their feature is enabled. > > I also provided diffs in the feature-flags and resourceresolver projects to > be able to see, what has been changed. > > WDYT ? > > Regards > Felix > > [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags
