Rodric, Carlos, I am fine too with the cut of date on December 1st. This will allow us to deprecate this feature in a coordinated way.
Thanks for your help, Martin > Am 31.08.2019 um 15:29 schrieb Carlos Santana <csantan...@gmail.com>: > > > I was never a fan of projections, very clever trick but the idea that an the > path to an endpoint was controlling a filter for the http response gives me > the heebie-jeebies :-) > > On the other side feels like a form of graphQL > > From experience don’t do the feature flag, and don’t try to implement in > another way. > > If you want to invest effort instead show an example/lib of using whisk > actions as front workers for graphQL might be more useful similar to > Cloudflare [1] when talking about projections and filtering responses. > > I like the idea of a cut off date. Do a /remind in Slack or a Whisk alarm > trigger :-) > > [1] https://developers.cloudflare.com/workers/templates/boilerplates/graphql/ > > - Carlos Santana > @csantanapr > > On Aug 30, 2019, at 9:53 AM, Rodric Rabbah <rod...@gmail.com> wrote: > >>> Assuming no one wants to bother with a feature flag for a deprecated >> feature, let's set a concrete date on which the PR will be merged. My >> suggestion is December 1, 2019. That gives ample time for downstream >> operators to do their deprecation process. >> >> I don't want to bother with a feature flag. I think the feature as >> implemented is unwieldy and kudos to those that did get it to work. Fine >> with me to defer it's already been open 4 months. >> >> That said, I have thought that we could provide projection capabilities but >> using X- headers (an argument for keeping some of the code around). I am >> not sure/convinced this feature in general though is useful. >> >> -r
