This is the proposal, dated 12th August 2001.
The implemented self-upgrader follows this proposal.
Self upgrade connectivity extension (proposal)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The VideoList URL is "http://www.heyrick.co.uk/budgiesoft/videolist/".
It is proposed to have an unlinked subdirectory called "upgrade". Within this
subdirectory will be three files:
1. "notes.txt"
A text file containing notes on the upgrade.
2. "upgrade.raw"
The actual upgrade file.
3. "version.txt"
A text file containing:
<major;two bytes>.<minor;two bytes><nl><oldmajor;2>.<oldminor;2><nl><size><nl>
like:
--8<--------
01.37
01.28
168960
--8<--------
Would specify that the upgrade currently available is for version 1.37.
This upgrade will successfully upgrade a version of VideoList LATER
than 1.28.
The upgrade file size is 168960 bytes (165K).
Other files may exist, such as:
4. "index.html"
Will be a spoof '404 Not Found' error. Only the more aware will notice
that it is the index which is saying the index doesn't exist. :-)
5. doupg.php3
For making a record of upgrades requested, times, etc. This will then
redirect to the appropriate file.
VideoList will include a VERY simple HTTP fetcher (using the Resolver and
Sockets (directly)); thus to be compatible with any Acorn-stack-derivation
(Argo, ANT, Freenet, Acorn etc).
Upon a request to check for updates, VideoList will download the "version.txt" file,
and process it using pseudocode similar to:
if (videolist_version == upgrade_version)
report("No new upgrade is available at this time.")
else
{
if (videolist_version >= old_version)
upgrade_prepare();
else
report("This version of VideoList is too old to upgrade. Please contact
support@heyrick.co.uk for assistance.")
}
Upgrade preparation will give you a choice of fetching the upgrade, or the
notes. The size is provided in the versions file, so the user has an idea of
the expected size of the download.
If user wishes to fetch the notes, VideoList will download them, then
Filer_Run to cause them to be loaded into a text editor. VideoList WILL
ALWAYS SetType the notes to be &FFF so that executable content cannot
be run.
After this, VideoList brings up the 'view notes / upgrade' prompt again.
If user wishes to fetch the upgrade, VideoList will download it and, if
download okay, will invoke the self-upgrade facilities. This will stall the
system, though only for a short time as the process is fairly quick.
There is no need to include file reference information on the WWW site, as
the upgrade file contains its own CRC checking.
Stack stuff:
All communications will be on port 80. There is no provision for others (like
8000 or 8080).
The header sent will be in the form:
--8<--------
GET /software/videolist/upgrade/file.extn HTTP/1.0
Host: www.heyrick.co.uk
Accept: */*
User-Agent: VideoList-Self-Upgrader; vlsufetch/#.##
--8<--------
OR in the form:
--8<--------
GET /software/videolist/upgrade/file.extn?user=<user>&vers=<vers> HTTP/1.0
Host: www.heyrick.co.uk
Accept: */*
User-Agent: VideoList-Self-Upgrader; vlsufetch/#.##
--8<--------
#.## is the fetcher version - this should be a number, such as "0.06".
The domain, path, and filename are built into VideoList.
VideoList, when requesting an upgrade, will supply a username and version
information. This is currently ignored, but a later version may use a php3
file to track upgrades. This allows us to determine what versions are being
upgraded, how you judge upgrades, and how often you look for upgrades.
In addition, it may be possible to write a smarter system, where it will look
at which version of VideoList you are using, and direct you to the most
appropriate upgrade file.
This facility allows us to make a site which serves you better.
The server sends two responses as it does not re-send the user name/version
following a redirect.
The reply from the server (actual reply from Argonet) is something like:
--8<--------
HTTP/1.1 200 OK
Date: Fri, 05 Feb 1999 12:02:56 GMT
Server: Apache/1.2.4
Last-Modified: Sun, 31 Jan 1999 15:28:11 GMT
ETag: "170882-2a40-36b4768b"
Content-Length: 18
Accept-Ranges: bytes
Connection: close
Content-Type: text/plain
00.21
00.19
89599
AE9F
2043
--8<--------
Note that two extra lines were returned. This is an undocumented addition to
the protocol - the fourth line is the CRC for the upgrade file, and the fifth
line is the size of the notes file.
Neither of these are currently used by the VLSU system, but you are welcome to
utilise them in your own fetchers (if you write one!).