We have designed a naming scheme that makes an immutable association between a location-independent filename, called a LIFN, and a specific byte stream. A higher-level location-independent name, called a URN, may be associated with a resource that is not tied to a specific byte stream. We have assigned such names to some of the software components in Netlib, and we have exported descriptions of these components to a Harvest search server. We have deployed LIFN and URN servers that provide LIFN and URN lookup services, and we have made available a modified version of Mosaic that can retrieve files named by LIFNs or URNs.
We have described mechanisms, based on a public key encryption system, for verifying the authenticity of LIFN and URN servers, of trusted file servers, and of resource descriptions. Although we have not yet implemented such mechanisms, we plan to do so soon.
Our naming scheme will help provide a uniform central interface to a virtual distributed software repository, such as the National Software Exchange, while preserving the advantages of distributed maintenance of contributed software and of file mirroring. Our consistency, authenticity, and integrity mechanisms will provide assurances that software components retrieved from independent sources are consistent with their verifiable descriptions. Use of LIFNs will allow value-added descriptions, such as critical reviews, to be unambiguously associated with the exact file or set of files that was reviewed. Referring to a LIFN also allows a researcher to unambiguously specify the exact piece of software used to produce and report experimental results.
As part of the BFD package, we plan to implement a replication daemon that acquires new files from remote servers, deletes files that are no longer wanted, and informs LIFN servers of the changes. These functions are similar to those provided by several existing mirror programs, such as the Netlib repository mirroring scheme described in [4], but with the addition of interacting with the LIFN database. The BFD replication daemon will be designed to perform its tasks very efficiently. Planned features include on-the-wire compression, checkpoint/restart, multiple file multiplexing (to allow for gradual transfer of very large files), integrity checking, and a protocol that works well over high bandwidth-delay links.
A collection manager program will also be part of the BFD package.
A collection manager will decide which files to acquire and which
ones to keep or throw away, based on access statistics and
site-specific criteria. The results of such decisions will
then be fed to one or more replication daemons.