Prev Up
Go backward to 2.1 The third party problem
Go up to 2 Registration

2.2 Garbage collection

Once registered, a version of a library must be kept available on the net until it has become obsolete.

A version of a library is obsolete iff there is no project library that imports it (directly or indirectly). A project library is a library of some registered project. The details of project registration have to be worked out yet. We might also want to extend the "imports" relation to an "refers to" relation by saying that LIB1 refers to LIB2 if LIB1 imports LIB2 or LIB1 was inspired by LIB2 or LIB1 is interesting for the understanding of the development history of LIB2. The details of how this relation should be specified need to be worked out as well.

Peter Mosses wonders whether the storage space needed for specs is big enough to warrant bothering with removing obsolete versions. Those who want to economize when adding an extra spec to an existing library may avoid copying the previous version by downloading the unchanged specs from it. Perhaps this style should even be required, since it lets users distinguish the new specs from the old ones. If individual specs are never duplicated unchanged when making new versions, PDM suspects that we're unlikely to experience problems with storing obsolete versions of libraries.

Moreover, it's important that online specs referenced from papers never disappear. Users should be able to register (e.g. by filling out a form or sending an e-mail) that a particular library version is to be kept forever ...


CoFI Note: M-5 -- Version: 1.0 -- 29 September 1998.
Comments to till@informatik.uni-bremen.de

Prev Up