Hi Carsten, In FeatureManager String[] getFeatureNames();
Javadoc says it returns all active features. Active might give an impression of this only returning enabled features, but rather it returns all available features. Changing the javadoc will also align with FeatureManager.isAvailable. And, I could not understand how context is passed on in FeatureManager.hideResource(final String featureName, final Resource resource) Is it the caller's responsibility to first check isEnabled(featureName, context), before calling hideResource? Thanks, -Amit -----Original Message----- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 19 December 2013 10:33 To: dev@sling.apache.org Subject: [RT] New Feature Flags API / Impl Hi, I've started with a new approach to implement the feature flags - the focus is on the API, which means what features do our feature flags have and how can they report it. (The implementation should be functional but I haven't checked it yet). I went back and forth with different approaches based on Bertrands prototype and all the discussions and I think this approach is the most promising one: The central service for client code is the Features service: public interface Features { String[] getFeatureNames(); boolean isAvailable(String featureName); ClientContext createClientContext(ResourceResolver resolver); ClientContext createClientContext(SlingHttpServletRequest request); ClientContext getCurrentClientContext(); } This can be used to find out which features are available and to create a client context - the context is either based on a request or on a resource resolver. The client context in turn can be used to find out whether a feature is enabled: public interface ClientContext { boolean isEnabled(String featureName); Collection<String> getEnabledFeatures(); } So a script can use this, to do things differently etc. In addition the Features services provides the "current client context" which is automatically available for a request. Now, somehow we need an API to define which feature is available and what it does - I came up with an extended version of the FeatureProvider (and I'm not so sure about this one): public interface FeatureProvider { String [] getFeatureNames(); boolean isEnabled(String featureName, ProviderContext context); Map<String, String> getResourceTypeMapping(String featureName); boolean hideResource(String featureName, Resource resource); } It's similar to the Bertrand's version, except that it takes a ProviderContext (which allows access to the request and resource resolver) and has two additional methods control the two most wanted features: hiding resources and changing of resource types. We could then implement this provider reading OSGi configurations or whatever to define features. All constructive feedback welcome - and as I said, let's first define the API Everything can be found at: http://svn.apache.org/repos/asf/sling/whiteboard/feature-flags/ Regards Carsten -- Carsten Ziegeler cziege...@apache.org
