Hi Bertrand, On Fri, Mar 21, 2014 at 6:39 AM, Bertrand Delacretaz <[email protected]> wrote: > Hi Justin, > > On Thu, Mar 20, 2014 at 7:56 PM, Justin Edelson > <[email protected]> wrote: >> ...This sounds mildly silly, but why don't we leave the feature in, but >> only enable it based on the presence of a particular feature flag?... > > I'd much rather have that optional sling:features support in a > separate bundle that we can move to contrib to make its status clear.
I thought it was deteremined that this *had* to go in the resource resolver. Attempts to do it through ResourceDecorator and ResourceAccessGate were shouted down firmly IIRC. > > Right now, even if one can turn of sling:features support in the > resource resolver, the functionality is present in a core bundle so we > have to maintain it, and the more people use it the harder it is to > remove it. We don't *have* to do anything. The Apache License is really clear about the fact that there's no implied warranty. We can very easily mark a feature as experimental and choose to remove it later. If anything, we should be doing more, not less of this. > > So, to refine my proposal I suggest: > > -Remove the sling:features support from the resource resolver bundle > -Remove the corresponding code from the feature flags bundle > -Maybe later make that functionality available again in a separate > experimental bundle > > Justin, would that work for you? Not really, based on my understanding that such an experimental bundle isn't actually possible (i.e. that sling:feature support can only be implemented in the Resource Resolver) and would instead be a fork of the Resource Resolver. I still think that if we are going to have Feature Flags *at all* in Sling, there should be a way of using them to impact resource resolution. This is a IMHO a natural use case. I think it is confusing for users when we have a Sling "feature" (using the term broadly) which so obviously relates to core framework functionality and yet isn't integrated into the framework. This happened with the Tenant API and I really don't want to see it happen with this. I remain -0 Regards, Justin > > Is anyone else opposed to that proposal? > > -Bertrand
