[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm: web/trunk/downloads.php
max at quendi.de
Tue Apr 21 14:16:57 CEST 2009
Am 21.04.2009 um 13:52 schrieb Travis Howell:
> fingolfin at users.sourceforge.net wrote:
>> Revision: 40038
>> Author: fingolfin
>> Date: 2009-04-21 10:55:42 +0000 (Tue, 21 Apr 2009)
>> Log Message:
>> Really fix download sizes & times for external downloads (= remove
> I'm not familiar with php scripting, so I didn't notice until
> commit. I
> was hoping another method could be used, so people could tell when
> exactly the last snapshots were generated, and the expected download
PHP isn't the problem. The data is on a different server, and it is
simply impossible to tell from a given URL on an external server how
big the data behind that URL is and when it was created. So for now,
we have to go without that data.
Some possible ways to improve this again in the future:
1) We could try to create a system at some point where the buildbot
server maintains a special file which lists all builds, the
corresponding URL, file size and creation time. This file could then
be used to dynamically create the list of all available builds (it
could even contain the SVN revision the build was made against). I.e.
the PHP on the downloads page loads that file and generates the list
of builds from that.
The problem with such a setup (besides the fact that the omnious
"somebody" would have to create it ;) is that it is somewhat fragile
2) A solution which would yield faster page load times would be to
push this "config file" from the buildserver via scp to the webserver
after nightlies have been generated. Drawbacks of that: The build
server needs write access to the webserver (opening up yet another
potential security problem). Oh, and if this fails, we'd display
outdated data on the downloads page... in general, the displayed data
might lag a few minutes compared to the data on the build server.
3) Create a "snapshot download" page on the buildserver, and link to
that. This way, the displayed data is always up-to-date, and we open
up no further security holes (well... except those we put into the PHP
code by sloppy coding... ;). It would be also the easiest to setup.
Drawback: Not as integrated into the main website. But then, it
wouldn't be *that* bad, would it?
If anybody can think of other options, speak up!
More information about the Scummvm-devel