Re: [pacman-dev] Download options

[Olivier Brunel]

On Sat, 3 Dec 2016 09:41:13 +1000
Allan McRae  wrote:

> I'm done.  All patches adding new options will not be considered until
> further notice.

hmm, so it seems I totally misunderstood (the intent) of your earlier
mail, all apologies. The intent never was to annoy/waste anyone's time.

Re: [pacman-dev] Download options

[Allan McRae]

On 03/12/16 06:31, Olivier Brunel wrote:
> On Fri, 2 Dec 2016 16:47:41 +1000
> Allan McRae  wrote:
> 
>> There was many thread and patches regarding this, so I am starting
>> another!
>>
>> So far there are two (maybe three) things people want options for to
>> do with the downloader.  I see most of these options being set in
>> pacman.conf and rarely specified on the command line.  Argue with me
>> if I am wrong here...
>>
>> Based on that assumption, here are my preferred option names (for both
>> pacman.conf and the command line):
>>
>> 1) Disable low speed timeout
>>
>> DisableDownloadTimeout
>> --disable-download-timeout
>>
>> I see no need to separate out speed and time timeouts.
>>
>>
>> 2) Set maximum download speed
>>
>> MaxDownloadSpeed
>> --max-download-speed
>>
>> I would also accept replacing speed with limit.
>>
>>
>> 3) (in a glorious future) Set maximum concurrent downloads
>>
>> MaxConcurrentDownloads
>> --max-concurrent-downloads
>>
>>
>> Any argument about these option names will need to be very clearly
>> justified.  I don't own a bike so have no need for a bikeshed.
> 
> Well, I could re-state how "Dl" is shorter than "Download" which might
> be nice, especially on command-line option -- but also looks to me like
> all those options would be about the longest ones yet, so far options
> can have "shortcuts" in their names, e.g. --dbpath not --databasepath or
> --nodeps not --nodependencies
> 
> It is possible those might be rarely specified on command line, doesn't
> mean they have to be as lengthy as possible because of it. Clear but
> short is good, and I feel that can be achieved here.
> 
> Doesn't have to apply to options in pacman.conf, and I guess they don't
> have to be named the same; There's already difference in case style, and
> it wouldn't even be the first time, e.g. --ignore vs IgnorePkg
> 
> 
> Why use "disable" as prefix while every other options usually goes with
> "no" instead? (--nodeps, --noconfirm, --noscriplet, etc)
> 
> 
> And while on the topic of consistency, let me add that almost all of
> pacman's options use a "single word style," i.e. no dashes in them:
> --ignoregroup; --noprogressbar; --downloadonly; etc Why not keep that
> up?
> 
> Yes, there are already expections to the rule (namely --print-format &
> --assume-installed), but those are the only two (I believe), I'm not
> sure it's good to make more. Consistency is a nice thing.
> 
> 
> So at least for command line, --nodltimeout and --maxdlspeed (and for
> the glorious future simply --maxdownloads) seem better to me.
> (Though if you don't like the "dl" bit, --nodownloadtimeout &
> --maxdownloadspeed would work too I guess; I do prefer the
> shorter versions myself, which I find still pretty clear/readable,
> but your choice.)
> 
> Either way we can use NoDownloadTimeout & MaxDownloadSpeed (and
> MawDownloads, or even MaxConcurrentDownloads) in pacman.conf; Yes the
> "No" prefix is also used there, so again feels better/more consistent
> that way.
> 

And we hit bikeshed again...

I'm done.  All patches adding new options will not be considered until
further notice.

Allan

Re: [pacman-dev] Download options

[Allan McRae]

On 03/12/16 06:54, Dave Reisner wrote:
> On Fri, Dec 02, 2016 at 04:47:41PM +1000, Allan McRae wrote:
>> There was many thread and patches regarding this, so I am starting another!
>>
>> So far there are two (maybe three) things people want options for to do
>> with the downloader.  I see most of these options being set in
>> pacman.conf and rarely specified on the command line.  Argue with me if
>> I am wrong here...
>>
>> Based on that assumption, here are my preferred option names (for both
>> pacman.conf and the command line):
>>
>> 1) Disable low speed timeout
>>
>> DisableDownloadTimeout
>> --disable-download-timeout
> 
> As a user, I would have no idea what this means. As the person who wrote
> the code that this affects, the thing which is most closely associated
> with time in this equation can hardly be called a "timeout". It's more
> of a threshold.
> 
> Some other suggestions, because my shed is better than your shed:
> 
> --disabledeadnetworkcheck
> --nocheckdeadnetwork
> --nodeadconncheck
> --nodeadconnectioncheck
> --namingishard
> 

I think timeout captures what this is trying to do and is the commonly
used term for this kind of functionality in various downloaders.  What
it actually captures (10sec at less than 1kb/s) can be documented in the
man page.

>> I see no need to separate out speed and time timeouts.
>>
>>
>> 2) Set maximum download speed
>>
>> MaxDownloadSpeed
>> --max-download-speed
> 
> I think I've pointed out before that this is a lie at best. You aren't
> actually throttling anything, you're just adding artificial delay. You
> can also do this from outside of pacman:
> 
> https://lists.archlinux.org/pipermail/pacman-dev/2016-September/021367.html
> 
> FWIW, it's no longer true that curl uses a flat average -- it's now a
> rolling window which should provide a smoother limiting mechanism.
> However, that's a very recent change (7.50.2), and requires a libcurl
> far newer than what we need for compilation (7.32.0).
> 

I realise this.  It is the intended effect of the option that I am
naming.  The fact that curl does not implement it very well should be
documented in the man page for that option.

And despite our assertion that pacman is cross distro, almost every
usage of it will have recent curl...

>> I would also accept replacing speed with limit.
>>
>>
>> 3) (in a glorious future) Set maximum concurrent downloads
>>
>> MaxConcurrentDownloads
>> --max-concurrent-downloads
>>
>>
>> Any argument about these option names will need to be very clearly
>> justified.  I don't own a bike so have no need for a bikeshed.
>>
>> Allan
> .
> 

Re: [pacman-dev] Download options

[Dave Reisner]

On Fri, Dec 02, 2016 at 04:47:41PM +1000, Allan McRae wrote:
> There was many thread and patches regarding this, so I am starting another!
> 
> So far there are two (maybe three) things people want options for to do
> with the downloader.  I see most of these options being set in
> pacman.conf and rarely specified on the command line.  Argue with me if
> I am wrong here...
> 
> Based on that assumption, here are my preferred option names (for both
> pacman.conf and the command line):
> 
> 1) Disable low speed timeout
> 
> DisableDownloadTimeout
> --disable-download-timeout

As a user, I would have no idea what this means. As the person who wrote
the code that this affects, the thing which is most closely associated
with time in this equation can hardly be called a "timeout". It's more
of a threshold.

Some other suggestions, because my shed is better than your shed:

--disabledeadnetworkcheck
--nocheckdeadnetwork
--nodeadconncheck
--nodeadconnectioncheck
--namingishard

> I see no need to separate out speed and time timeouts.
> 
> 
> 2) Set maximum download speed
> 
> MaxDownloadSpeed
> --max-download-speed

I think I've pointed out before that this is a lie at best. You aren't
actually throttling anything, you're just adding artificial delay. You
can also do this from outside of pacman:

https://lists.archlinux.org/pipermail/pacman-dev/2016-September/021367.html

FWIW, it's no longer true that curl uses a flat average -- it's now a
rolling window which should provide a smoother limiting mechanism.
However, that's a very recent change (7.50.2), and requires a libcurl
far newer than what we need for compilation (7.32.0).

> I would also accept replacing speed with limit.
> 
> 
> 3) (in a glorious future) Set maximum concurrent downloads
> 
> MaxConcurrentDownloads
> --max-concurrent-downloads
> 
> 
> Any argument about these option names will need to be very clearly
> justified.  I don't own a bike so have no need for a bikeshed.
> 
> Allan

Re: [pacman-dev] Download options

[Olivier Brunel]

On Fri, 2 Dec 2016 16:47:41 +1000
Allan McRae  wrote:

> There was many thread and patches regarding this, so I am starting
> another!
> 
> So far there are two (maybe three) things people want options for to
> do with the downloader.  I see most of these options being set in
> pacman.conf and rarely specified on the command line.  Argue with me
> if I am wrong here...
> 
> Based on that assumption, here are my preferred option names (for both
> pacman.conf and the command line):
> 
> 1) Disable low speed timeout
> 
> DisableDownloadTimeout
> --disable-download-timeout
> 
> I see no need to separate out speed and time timeouts.
> 
> 
> 2) Set maximum download speed
> 
> MaxDownloadSpeed
> --max-download-speed
> 
> I would also accept replacing speed with limit.
> 
> 
> 3) (in a glorious future) Set maximum concurrent downloads
> 
> MaxConcurrentDownloads
> --max-concurrent-downloads
> 
> 
> Any argument about these option names will need to be very clearly
> justified.  I don't own a bike so have no need for a bikeshed.

Well, I could re-state how "Dl" is shorter than "Download" which might
be nice, especially on command-line option -- but also looks to me like
all those options would be about the longest ones yet, so far options
can have "shortcuts" in their names, e.g. --dbpath not --databasepath or
--nodeps not --nodependencies

It is possible those might be rarely specified on command line, doesn't
mean they have to be as lengthy as possible because of it. Clear but
short is good, and I feel that can be achieved here.

Doesn't have to apply to options in pacman.conf, and I guess they don't
have to be named the same; There's already difference in case style, and
it wouldn't even be the first time, e.g. --ignore vs IgnorePkg


Why use "disable" as prefix while every other options usually goes with
"no" instead? (--nodeps, --noconfirm, --noscriplet, etc)


And while on the topic of consistency, let me add that almost all of
pacman's options use a "single word style," i.e. no dashes in them:
--ignoregroup; --noprogressbar; --downloadonly; etc Why not keep that
up?

Yes, there are already expections to the rule (namely --print-format &
--assume-installed), but those are the only two (I believe), I'm not
sure it's good to make more. Consistency is a nice thing.


So at least for command line, --nodltimeout and --maxdlspeed (and for
the glorious future simply --maxdownloads) seem better to me.
(Though if you don't like the "dl" bit, --nodownloadtimeout &
--maxdownloadspeed would work too I guess; I do prefer the
shorter versions myself, which I find still pretty clear/readable,
but your choice.)

Either way we can use NoDownloadTimeout & MaxDownloadSpeed (and
MawDownloads, or even MaxConcurrentDownloads) in pacman.conf; Yes the
"No" prefix is also used there, so again feels better/more consistent
that way.

Hopefully there were some clear justifications in there. :)

Cheers,
-j

[pacman-dev] Download options

[Allan McRae]

There was many thread and patches regarding this, so I am starting another!

So far there are two (maybe three) things people want options for to do
with the downloader.  I see most of these options being set in
pacman.conf and rarely specified on the command line.  Argue with me if
I am wrong here...

Based on that assumption, here are my preferred option names (for both
pacman.conf and the command line):

1) Disable low speed timeout

DisableDownloadTimeout
--disable-download-timeout

I see no need to separate out speed and time timeouts.


2) Set maximum download speed

MaxDownloadSpeed
--max-download-speed

I would also accept replacing speed with limit.


3) (in a glorious future) Set maximum concurrent downloads

MaxConcurrentDownloads
--max-concurrent-downloads


Any argument about these option names will need to be very clearly
justified.  I don't own a bike so have no need for a bikeshed.

Allan