I (semantically) prefer deprecated vs removed ... and of course deleting code is always more valuable then adding code so a big +1 to the plan for removals.
Jim On 1 July 2018 at 13:04, Daniel Stenberg <dan...@haxx.se> wrote: > On Sat, 30 Jun 2018, Daniel Stenberg wrote: > >> HTTP Pipelining was never enabled by default by the large desktop browsers >> due to all the issues with it. Both Firefox and Chrome have also dropped >> Pipelining support entirely since a long time back now. We are in fact over >> time becoming more and more lonely in supporting pipelining. > > > Here's a plan on how to deprecate pipelining support from libcurl! > > 1. In 7.62.0 (release planned to happen in September 2018), we add code that > ignores the "enable pipeline" option setting). The *setopt() function would > still return "OK" though so the application couldn't tell that this is > happening. > > Users who truly need pipelining from that version will need to modify the > code (ever so slightly) and rebuild. > > 2. Six months later, in sync with the planned release happen in April 2019, > (might be 7.66.0), assuming no major riots have occurred due to this in the > mean time, we rip out the pipelining code. It is in the order of 1000 lines > of libcurl code. > > Left to answer: should the *setopt() function start to return error when > these options are set to be able to tell when they're trying to use options > that are no longer around or should we maintain behavior as much as > possible? > > > Is this plan compatible with our API/ABI guarantees? > > Yes in fact it is. Pipelining is and was always just a "wish" from the > application's perspective and it can never really be guaranteed to happen. > From an application's perspective, this just makes the wish never come true > over the wire. > > Appeal? > > If you want to object to this plan and decision, please bring it up here on > the curl-library mailing list and explain to us why your use case breaks > terribly by this action with no useful work-arounds. > > > Since this is now the second item on the "to be removed" list (axTLS being > the first), I figure maybe I should setup a page somewhere to help us keep > track of them... > > - As always, your input is appreciated! > > > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html