Hi, On Mon, Jan 20, 2014 at 9:35 AM, Felix Meschberger <fmesc...@adobe.com> wrote: > Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <cziege...@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
