In my note on Charlie Landau’s proposal for banks I mention a number of ways that banks may differ. I intend here to explore some of these to see if they really solve problems.

We have been vague about how an application might manage the distribution of its components in a distributed capabilities framework. The problem is introduced here.

Lets do a gedanken experiment. Application component generation logic, G, at site A decides to create a component at site B. G at A acquires a (remote) key to a bank at B. Suppose that G merely invokes local factories passing the remote bank key. The local factory will reject the presumed remote bank key as counterfeit.

G, instead, acquires a remote key to a corresponding factory at site B, and makes the same invocation. This time the factory receives an official bank key (First National Bank of B) and proceeds to produce the object which then returns to the factory requestor G, via the remote return key. Now G holds the unique remote key to the new object at B. (The comm system at B holds the real key to the new object.) This sounds good but does not address the purpose of this note.

Suppose that we have two loosely coupled systems (shared disks, separate RAM), each with a continuous load, and we wish to upgrade hardware on the second system. (The systems share disk drives but not disk space. They have separate ranges.) We wait until a time where the total load can be handled by the first system and shut down the second system, and then signal the first to assume the load in the checkpoint found on the second system’s disk, in addition to its own load. This takes kernel mods to

Since there are no capabilities between the two loads the omelet is not really scrambled and the second machine can reclaim its load as easily as it shed it. We are getting closer but not yet to the purpose of the note.

Suppose that we want a compound object on demountable media. We want to be able to move the object, behavior and state, from one system to another. It seems promising to start with a bank selling space only on that demountable drive. Small modifications in current bank logic could arrange for such a bank. Sending the DB (demountable bank) to a normal factory ends up in easy cases with an object implemented by a domain whose program segment is not on the demountable media. If the media were remounted on another system, and the new system had a program segment with the same bits, one can imagine protocols reattach the head to the body and proceed. This scenario raises issues of proprietary rights of the program owner which capabilities do not address except as to provide new opportunities usage sensitive pricing. Still the special bank seemed to play a role in the partial solution. While we have raised this scenario we point out that demountable media are likely to be less protected from access that bypasses capability discipline. As a consequence the administrator of physical range keys may refuse to release range keys to such media except under special precautions. There remain security problems with this idea.

I claim that just as a page is a different type than a node or a meter, then so should a SPARC domain be a different type than an x86 domain. They should have different alleged types. The standard public directory of useful tools would include domain creators for both. If I have a segment with SPARC commands defining useful behavior I shall require a SPARC domain to obey it, no matter what sort of machine I am running on. If I know that I am on an x86 then I will choose a segment with x86 commands if I have that option. If I do not and there is a remote SPARC to which I hold remote keys then I can copy my SPARC code there and build my application there and probably win.