curl / Mailing Lists / curl-users / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Opinions on the naming of a new option?

From: X M via curl-users <>
Date: Mon, 18 Nov 2019 09:54:01 +0100


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

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

But ... naming is hard ... just my 2 cents

>> Le 17 nov. 2019 à 21:43, Rich Gray via curl-users <> a écrit :
> Daniel Stenberg via curl-users wrote:
> Hi,
> Soon, when doing parallel transfers (-Z) to the same host name with more than one transfer, the curl tool will prefer that the second transfer waits for the first connection to be established to then see if it can perform the second transfer multiplexed over that same connection. Thus ideally using fewer connections when possible.

And this is plain -Z or --parallel?

Would --parallel_multiplex=n (or shorter --parallel_mx=n) with n=1 describe this mode. --parallel_mx_only[=n] prevents additional connections? Maybe just --multiplex[_only] ?

n sets a simultaneous transfer limit.

> There will be a new command line option that tells curl to rather *not* wait to check for this but instead prioritize to create a new connection immediately for subsequent requests rather than to wait and see.
> How should we name this new command line option? Jay and I have discussed it in the PR and the current list of alternatives include (in alphabetical order):
> --parallel-at-once
> --parallel-connect
> --parallel-directly
> --parallel-nowait
> --parallel-preferred

    --multiple_connect[_only][=n] (or back to your --parallel_connect)


       start a new connection if the initial connection
       isn't established in n milliseconds. Otherwise multiplex.

> I don't think any of them feels "perfect". Any better suggestions, ideas, thoughts, complaints?

Yeah, parallel is ambiguous. You're trying to distinguish between multiplexing over connections and multiple connections, but don't really name either method.

> The patch and discussion so far exists in PR 4500:

Initially I misunderstood what was wanted and came up with the word 'simultaneous' to add to the word soup, but again, simultaneous what?

I wonder if it would be possible to use options in the rc file to set up what -Z means?

- Rich

Received on 2019-11-18