Persistence is something that is entirely normal in MUDs, so this whole section may seem amazingly obvious to those of you used to MUD programming. However, it is very abnormal in operating systems, but see EROS.
In an operating system, if you want to open a file, you go and get a list of files, then ask for permission to open it. This makes it easy to deal with reboots: you just go look for the file again.
Obviously, this can't work in a capability system: where do you get the list of files from? In the context of a MUD, there would need to be some way to search through all the rooms to find the one you were in to ask for capabilities on that room. There is no such ability. OK, that's not quite true, the Storage object can, and does, have such an ability, but only for purposes of implementing persistence.
So, the mud simply stores everything. Every few minutes, each object is written to disk, along with all the capabilities it has acquired. So there is no rebooting, really: after a crash or whatever, the MOZ is brought back up as though nothing had changed.
Actually, that may not be quite true: only the capabilities that are
saved as part of running toRecord on that class are stored, so stuff
that is only being stored in running code or cache attrs is not
preserved.
Capabilities, because they are simply implemented as a record of Oz names, are stored as per normal by the Storage object. The object wrapper handles are turned into Oz names on the way out and converted back on the way in.
For that to work, the newly loaded object that the capability is for
must remeber what the names were that it had associated with various
methods, especially since this is handled in the wrapper. The way that
this is done is to simply have the information be stored as a dictionary
in the wrapper; the wrapper has code in it to intercept the toRecord
call and add the capability information, and also to intercept the
fromRecord call and extract it again.