[quake3] HTTP/FTP Downloads (again)

[Tony J. White]

On Fri, Sep 08, 2006 at 10:54:23AM +1000, Shane Isley wrote:
> The one aspect I think needs to change is a server actively disabling http 
> downloads. A client should get the missing files as fast as possible; it's what 
> the patch does so well.
> 
> In my opinion
> cl_allowdownload    [integer]
>    It should be the clients single download switch.
> 
>    0 - don't download
>    1 - UDP downloads
>    2 - HTTP & UPD downloads
> 
>    Alternatively use a 0,1,2,4 bitmask.

We don't want to change cl_allowDownload.  The reason is this cvar needs
to default to 0 (no downloads).  This setting should apply for any type
of download.  However, we do want to change the default behaviour of
downloads so that the default is to use cURL by default, then fallback
to UDP.  Therefore, having a seperate cvar just for controlling download
behaviour, but not for enabling/disabling it is justified.

I'm planning on dropping the cl_wwwDownload cvar and replacing it with
a bitmask value to match the settings of sv_allowDownload.  Like
sv_allowDownload the bitmask values would be:

1 - traditional UDP downloading allowed
2 - download redirection allowed (cURL)

valid settings for this cvar would be:

1 - udp downloads only
2 - redirected downloads only
3 - redirected downloads allowed, but fall back to udp if server doesn't
    support redirected downloads

The default would be 3.

I'm not sure what to call it, perhaps cl_downloadMethod?

> cl_dlURL   [string]
>    This would serve a similar function to sv_dlURL. It is the fallback when the 
> server doesn't supply sv_dlURL (ie the server operator doesn't want to or can't 
> be arssed to offer the pak's via http). It allows the client to try a trusted 
> URL where the pak's might be; if unavailable the client would request to 
> download via UDP. If all three have failed at that point, i guess it's time to 
> google or find another server.

I don't think this would be very valuable.  The trouble is there are lots of 
pk3 files floating around the internet's tubes that have the same name but
are different files.   I think any redirect downloads a client does should
be done on behest of the server they're trying to connect to.  That way
if you spend 30 minutes downloading the wrong pk3 you know who to blame
(server operator).

I can see why you might want this feature, but it seems like it would 
only see a very limited use and could result in confusion/frustation for
those who do use it.

> sv_allowdownloads [integer]
>    This should keep it's original role; the servers gatekeeper for direct UDP 
> downloads from it process to quake3 clients.
> 
>    0 - no UDP downloads
>    1 - allow UDP downloads
> 
> sv_dlURL   [string]
>    This is the place where the server can either actively help clients by 
> displaying a URL for it's files. If left blank  "no harm no foul" the client 
> can try from it's fall back cvar cl_dlURL.
> 
> sv_wwwDlDisconnected    [integer]
>    Sounds like this is necessary from your comments on bz.
> 

sv_wwwDlDisconnected was dropped because all off the download settings
except for sv_dlURL on the server were consolidated into sv_allowDownload to 
address space conserns.

-Tony