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?
Shipping an "experimental" feature which can be toggled on or off seems like a perfect use case for feature flags. WDYT? Justin On Thu, Mar 20, 2014 at 2:26 PM, Carsten Ziegeler <[email protected]> wrote: > I think, let's remove this stuff from the resource resolver for now, > experiment with the flags in general and once we have a better picture, we > can add it back again - either in the same way or totally different. We > could also move the code to a branch or whiteboard so people can install > the experimental resource resolver. > > Carsten > > > 2014-03-20 11:17 GMT-07:00 Carsten Ziegeler <[email protected]>: > >> The post problem is fixed, btw - features are only evaluated for GET/HEAD >> requests >> >> Carsten >> >> >> 2014-03-20 8:32 GMT-07:00 Justin Edelson <[email protected]>: >> >> Hi, >>> >>> On Thu, Mar 20, 2014 at 11:19 AM, Bertrand Delacretaz >>> <[email protected]> wrote: >>> > Hi, >>> > >>> > On Thu, Mar 20, 2014 at 4:16 PM, Justin Edelson >>> > <[email protected]> wrote: >>> >> ...Feature Flags may look similar to >>> >> ACLs, but they are useful for a different set of use cases than ACLs. >>> >> Feature flags are about "orchestrating" features. Resource access is >>> >> *one* part of this orchestration, but it is not the only part... >>> > >>> > Yes, when I said "similar to ACLs" this is specifically about the >>> > resource access bits that we have in the resource resolver now. >>> > >>> > I'm totally convinced of the utility of feature flags in general, it's >>> > just the magic in the resource resolver that I'm objecting to. >>> >>> Where you need that magic (or where it is higher value) is where a >>> "feature" is composed of both behavioral changes in scripts *and* >>> resource hiding. That's what I meant by "orchestration" and something >>> I think would be challenging to do without support in the resource >>> resolver. >>> >>> Regards, >>> Justin >>> >>> > >>> > -Bertrand >>> >> >> >> >> -- >> Carsten Ziegeler >> [email protected] >> > > > > -- > Carsten Ziegeler > [email protected]
