Re: Opinions on the naming of a new option?
Date: Sun, 17 Nov 2019 15:30:39 -0500
Daniel Stenberg via curl-users wrote:
> 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):
--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?
Received on 2019-11-17