Re: Opinions on the naming of a new option?

On Mon, 18 Nov 2019, X M via curl-users wrote:

> If I get it right, using this new « --parallel-connect » option would make «
> -Z » behave like it currently does (before pull/4500) : opening up to «
> –parallel-max » connexions to a same hostname for new requests, without
> trying to minimize the number of connexions to hosts that could have handled
> HTTP/1.1 pipelining or HTTP/2 multiplexing

Yes! (But we don't do HTTP/1 pipelining, we talk about HTTP/2 multiplexing for
now, with HTTP/3 multiplexing coming...)

Lots of people have read this as an option to ask for multiplexing or not, and
that is certainly not the case. It is just a question of prioritization:
should curl prefer new connections rather than waiting for possibly
multiplexing. In both cases, curl will go with multiplexing if there already
is an existing connection in the cache that can accept it. The question is
what curl should do when there is no such connection available.

> I would then call that option « —parralel-pipewait », with possible values
> 1/true (default) and 0/false

The underlying libcurl option to prefer waiting for a "pipe" is called
"PIPEWAIT" and that is what I want to set as default going forward. So, the
option here would be the reversed: do not wait for a pipe since it will do
that otherwise.

Also, I don't think "pipewait" is very user friendly as a term.

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-11-18