RISCOS.org Links Database Automaton Usage
The main Links Database engine can be interrogated by your own software which can aid you with package management or simply offering users the ability to upgrade if a newer version of an application is available.
To do this, you can consult a special version of the database which produces a vastly simplified, plain text output. Two steps are required:-
Step 1 - Finding out the unique database reference
Using the database search in the normal fashion, search for the application or module that you require. When you find it, view the full details page and make a note of it's unique Download ID. This is shown at the bottom of the Information section in the right-hand column.
The unique download ID is in the form xxyyyy where xx is a two digit alphabetic code signifying the catagory and yyyy is a four digit number.
Note this ID for future reference.
Step 2 - Checking the latest version of an entry
Armed with the unique database ID you can now interrogate the database using the following URL:-
where IDNNNN is the unique database ID, as found in step 1.
Those of you who understand HTML and cgi scripting will notice that the line above is calling the cgi-bin/linksdb script on our server with three parameters. These are:-
Extra code required
If implementing version checking from software then you obviously don't want the user to have to enter the above URL in a standard web browser. Instead you want to implement some code in your application to fetch the reponse from RISCOS.org as painlessly and 'invisible' to the user as possible.
To do this you require an HTTP fetcher module or utility which will fetch a specific URL and save it locally as a file, which you can subsequently interrogate. Several such utilities exist for RISC OS, such as wget or cURL. The examples below will use wget.
wget is a command line tool for retrieving files from the web using http and ftp. It has a number of parameters, but for our purposes we only need three parameters; the URL to fetch (described above), and two output files; one for logging the output of wget and one for storing the actual database results retrieved from RISCOS.org. The logging file is optional, but if used it will suppress output to the screen, which is useful for implementing into your own code.
The output files can either be standard files stored on a local disc or RAM disc, or could be sent to pipefs: - depending upon your coding skills and/or requirements.
An example CLI command using wget and interrogating the database to find the latest version of the tinct module would be:-
wget http://www.riscos.org/cgi-bin/linksdb?d=x&pkg=x&q=mo0038 -o RAM::RamDisc0.$.log -O RAM::RamDisc0.$.pkginfo
(all on one line as a single command)
The first parameter is the full URL of our database (as described above)
The second parameter (optional) is the log file of the output from the wget command. In this example it will be saved as log on a local RAM Disc. This uses the -o parameter followed by the required filename.
The third parameter is the file to store the actual output returned from our server. In this example it will be saved as pkginfo, also on a local RAM Disc. This uses the -O parameter followed by the required filename.
The resulting file
The resulting file fetched from our server will be in plain text format and contain three lines (separated by linefeeds (\n). These are the name of the file, the latest version listed in the database and lastly, the URL of the download file for the latest update.
Eg. for tinct, the result will be:-
name: Tinct ID: mo0038 version: 0.13 url: http://www.tinct.net/download/tinct_013.zip
N.B. The output shown above is a live example from our database, proving it works - although if the entry for tinct is corrupt, you may see incorrect details displayed above.
You can thus read this file in order to compare a version number or to download the latest version. Indeed, if you submit the URL of the download to wget you can download the actual update, so could incorporate this into your application updater.
Each line is divided in two parts; the field name, followed by a colon and a space, then the actual result from our database. Thus you can extract just the value of each line by reading into a string variable, eg. var$ and then performing the following operation:-
Using the methods described above you could incorporate version checking and automatic updates into your own software. However, in order to keep the load on our server to a minimum, I wouldn't recommend checking for updates more than once a day. Indeed, unless you update your software very frequently, you'll probably find that checking once a week is adequate.
If you require more help, please contact us.
Last edit: 10th Apr 2016 at 4:55pm (1079 days ago)