Summary

  • Netlib's creators described an automated email service in 1987 that returned requested mathematical routines and their subsidiary routines. It handled small, useful pieces of software without mailing an entire library.
  • The repository took on the work of finding dependent code. Editors, indexes and search settings made that service useful; the September 1995 account shows that its email interface still offered some retrieval choices missing from the newer web interface.

Some people said please to Netlib. They apparently thought a person was reading their request for software. The machine could cope with a little courtesy. It had rather less patience for arbitrary English.

That detail comes from Jack J. Dongarra and Eric Grosse's May 1987 account of a service that sent mathematical programs by email. Users sometimes wrote a polite sentence, put their request in the subject line, or used the digit 4 where the instructions expected “for” or “from”. The authors accommodated small variations. A simple request could reach an automatic server even when its sender imagined a helpful colleague at the other end.

The helpful colleague was a collection of scripts and programs. Netlib had servers at Argonne National Laboratory and AT&T Bell Labs. A message could ask for the catalogue, an index to a particular library, named routines or a keyword search. The reply carried the requested material. Email was already useful across networks whose other services and addressing arrangements varied.

There was a practical reason to send software this way. Numerical researchers often needed a small routine to perform part of a calculation. Obtaining a large collection on magnetic tape brought more material than they wanted, along with the work of reading a tape written for another system. Netlib let the request shrink to the problem in hand.

But a small routine has a habit of calling other routines. Fetch the first file and the job may still be unfinished. Its subordinate pieces can live elsewhere in the collection, and those pieces can call further pieces. The researcher who wanted to do some mathematics can end up organising a reunion of missing files.

Netlib did that gathering at the repository. The 1987 paper's examples show a request for a routine returning the routines it called as well. Users could ask for just the named file, exclude a branch of subsidiary code, or receive a list of filenames. The ordinary request included the supporting pieces, while narrower requests gave experienced users control over what arrived.

The server interpreted the library names as a search list and used the system loader to resolve routine names. It turned the resulting map into filenames to send back. The calculation itself would happen at the recipient's machine. What Netlib supplied was the code assembled for that next step.

The August 1994 introduction to Netlib's services described the same bargain: requested routines came with subsidiary routines and any requested documentation or test programs supplied by their authors. By then, users could also reach the collection through a graphical Xnetlib interface and web browsers. The delivery routes were multiplying around a collection that still needed people to maintain it.

Finding the right entry was another job. The project's index guidelines, begun in 1992, asked descriptions to explain what problem a file solved. That explanation had to make sense on its own, because a keyword search might pull it out of its surroundings. A program's cryptic filename was a poor substitute for someone saying what it did.

Editors also decided what belonged in the collection. The September 1995 description by the repository's maintainers assigned them questions of scope, novelty and quality. The automatic reply sat on top of that human selection and the records describing how pieces of code depended on one another.

The same 1995 account contains a pleasing reversal of expectations. The Tennessee web interface offered links for a single file and for the file together with its dependency tree. Yet it lacked some of the email interface's flexibility, including excluding a subtree and choosing the directories searched for dependencies. A browser made the collection easier to approach; a carefully written email could still ask a more particular question.

Netlib's achievement was tucked inside the reply. Someone asked for a routine, and the service gathered the code that routine called before sending it. The download had become a small act of organisation. The user could save the thank-you note and get on with the calculation.