MasterDistribution.site : Java Glossary

<a name="CMOSSAVE"></a> <a href="zips/cmossv32.zip">cmos saver</a>

If the author issues a new version, all he need do is update the products.html file to point to the new zip, cmossv33.zip. In theory then, all obsolete copies in the universe will eventually be automatically updated.

The PAD file contains the masterdistribution site, plus other information. So it supeceeds this notion.

If the author wants to totally obsolete a program, rather that update it, he can redirect the URL to a dummy file called discontinued.zip which must actually must exist on some website.

End users can then check if they have the latest version. Install software can automatically check if it has the most recent version. Automated checker programs might just insist on a zip file name match, or a more precise date/time/size match. It is possible for a program to determine this without actually downloading the potentially new version. If the current version is obsolete, the new version can be automatically downloaded.

The scheme also works manually without any special software. The end user just views the MasterDistribution.site URL in his web browser and decides for himself it is newer and read about the new features to decide if he wants the update.

A redistributor can periodically check if it has the latest version of all the zips he distributes. If not, it can automatically delete the old and download the new, which includes a potentially different MasterDistribution.site URL.

For this to be fully automated, any descriptive information (e.g. keywords, *.DIZ) must be embedded inside the zip so that it too will be automatically updated. One major problem is different redistribution sites want different descriptive information. We need a global format that is easy to prepare, that permits embedded HTML for pretty formatting the descriptive information and that allows for site-specific extension keywords.

The scheme also allows for virtual redistributors. They don’t have any files on their webserver to download. They just post the URLS from the various MasterDistribution.site zips they want to distribute. They don’t need do anything to maintain a link to the latest version.

The scheme has several weaknesses.

1. It requires the author to forever maintain the original URL. He is in trouble if he later wants to split the html over smaller pages. He can create new split pages, but must almost forever maintain i.e. keep up-to-date, the old one.
2. It does not automatically notify holders of updates.
3. It does not provide information on how frequently to poll for updates. Perhaps the scheme could be extended to embed this in the products.html HTML or the MasterDistribution.site file.
4. It could end up generating an overwhelming amount of traffic for a small master website. That might be alleviated by extending the scheme to SecondaryDistribution.site files.
5. The scheme should eventually be supplanted by the URN scheme. If the MasterDistribution.site scheme becomes too successful it might delay adoption of a proper URN approach.
6. People will probably totally misunderstand the scheme and put the ZIP file URL directly in the MasterDistribution.site file instead of a permanent indirect HTML link to it. They may not understand why only *.zip and *.jar files can be distributed this way.
7. The link really should be implemented with a direct link to a downloadable master description file containing among other things the URL of the downloadable. The political problem of defining the mother of all description files and getting sites to accept the format is all but impossible.