At 05:19 PM 12/21/98 -0800, Norman Hardy wrote:
>Perhaps holes are dispensible (but see
><http://www.mediacity.com/~norm/CapTheory/Retrieve.html>); I think,
>however, that real durable objects must suffer a variety of vulnerabilities
>in practical situations. I really want to know if I can live with out some
>six year old 15 megabyte library, or must I continue to pay for this
>proprietary Runge-Kutta service.
[#]The idea of durable objects always bring up the question, how durable? When we turn a computer off for the last time, we ask, what is on it that we will need. It seems in all cases, you want to be able to play what if I no longer had this object. There seem to be three ways of dealing with this problem:
(1) Caveat Programmer, as in C. Nothing happens to pointers to deleted objects. Features: Low overhead, obscure bugs, security exposures.
(2) Garbage Collection, as in Lisp/Smalltalk/Java. Now the question becomes, why isn't this object being deleted and how long do I have to keep paying to store it. Features: Relatively high maintenance overhead, not knowing why you are keeping an object.
(3) Zap, as in KeyKOS, where deleted pointers have well defined semantics. Now the question becomes, when I zap something what am I going to break. Features: Relatively high pointer following overhead, not knowing what will break when I zap something.
In case 2, we can build tools that act below the level of abstraction of the objects which will tell us why an object is being kept. It may even be possible to automatically identify "interesting" objects, e.g. those objects with few in-pointers which pin a lot of space.
In case 3, we might be able to build tools which would identify all the objects which hold pointers to an interesting object. The tool set may be quite similar to the case 2 tool set.
In either case, the tools operate below the level of abstraction of the objects.