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 <daniel_at_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
Received on 2018-07-01