2008-01-18
I had promised to write something about the directory structure for the Update program when we get to FreeDOS 1.1. Here it is. Let me know what updates I need to make.
This document attempts to summarize our discussion on the FreeDOS mailing lists (11/30/07-12/4/07) of the FreeDOS Update program:
In the following, "..." represents the hostname and directories leading up to the "distributions" directory. On the ibiblio server, "..." is "http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/". Other mirror sites will have a different host name, and may have a different leading directory path.
The distribution of FreeDOS 1.0 was located on the ftp/web servers as ".../distributions/1.0" with a flat directory layout; the directory contained ISO files and a single "pkgs" directory that contains every ZIP and associated LSM for every package in the distro.
Under FreeDOS 1.1, we wanted to organize things slightly differently:
I would like to support a FreeDOS Update program for a FreeDOS 1.1 distro, by doing a re-write on how we manage package information on the www.freedos.org web site. Today, we have the LSMs from (almost) every package stored on the www.freedos.org web server, in a directory structure that mirrors the disk sets (base, devel, edit, ...). There's a simple CGI that displays the contents of the LSM files in a pretty way, generating different "views" of the data via web pages. This makes it fairly easy to keep the software list up-to-date; an author releases a new version of his/her software, and the webmaster (usually me) puts the updated LSM on the www.freedos.org web server. The data is instantly available to the CGI.
I would like to re-write the software list to use a database, and have front-ends that happen to generate LSM files, web pages, XML files, etc. Using a database will make new front-ends (i.e. for different "views" of the data) easier to create. This helps not just the user who is looking for FreeDOS packages, but also helps search engines that may have an easier time crawling our software list (i.e. a user who Googles for "Freedos diskcopy" would likely get a better hit from the software list view ... which points directly to where to get it.)
The trick (for me) will be to create an "import" system so that I can just use the LSM that was provided in the package, and push it into the database. But a benefit to that is that the import process can do some data cleanup on the LSMs (currently, not all the LSMs use the correct LSM format.) I might also create a "self service" web application that allows developers (who have the correct rights to do so) to import LSMs or to use a form to manually enter the data (for those packages that do not include an LSM.)
I can automated an export of the data into an easily-read file format, perhaps nightly, showing the latest versions of each package (for example, updated since a particular date - the date of the FreeDOS 1.1 distribution.) I'd like to put a file in .../distributions/1.1/updates/ (one file for each disk set) that lists the packages that have been updated since the release of the 1.1 distro, the versions of the updated packages, and where to find them. I'd really prefer to send back an XML file (makes inter-system operation much easier) but we can keep the XML syntax easy enough that it could be correctly read by a non-XML parser.
The file format I propose is:
<pkglist> <pkginf> <title id="CHOICE" /> <version id="5.1" /> <entered id="2008-09-20" /> <pkg id="choic51x.zip" /> <spkg id="choic51s.zip" /> </pkginf> </pkglist>
The fields are lifted directly from the LSM definition:
The file would be named after the disk set for which there are updates. For example, the file that describes the latest updates for the 'base' disk set would be named .../distributions/1.1/updates/base.xml. For the 'edit' disk set, .../distributions/1.1/updates/edit.xml. For 'devel', .../distributions/1.1/updates/devel.xml. And so on.
It is possible to extend the above XML definition to allow for updates from ALL DISK SETS to appear in a single file. However, this could become quite large, and would contain a lot of data that would be of no value for users who did not choose to install everything. So I think it is a good idea to keep each disk set in a separate file.
Under the FreeDOS 1.1 distro, the operation of the FreeDOS Update program would need to be as follows: