Capabilities are protected names. A capability is a name in that it designates something within a computing system. Just as “/usr/bin/grep” names something in Unix so does a capability name something in Keykos. I can’t depict capabilities here for they are not composed of characters. The program that holds and can wield a capability does not have access to the bits of that capability. Message passing primitives in capability systems allow a holder of a capability to send it in a message to another program. The Unix name “work.c” may name different files for different programs and if I pass “work.c” to you it will probably access different data for you than for me. If I pass you a capability, on the other hand, it will yield the same data for you as for me. Unlike names in directories, capabilities suffice to access the designated thing whereas classical directories include extra protection structures designed to define who can access the designated thing. When a program passes a capability to another, it has passed its authority to the other. Here are some notes on names and capabilities, and why capabilities should not appear as bits to the application.
When a programming language is adapted to a capability system it is customary to arrange that some language identifiers designate capabilities, perhaps by denoting an integer index into a list of capabilities. It is also customary for command systems to hold capabilities in a directory for users under names chosen by the user. Unlike classic operating systems, however, such a directory seldom plays a role in the execution of the application and most application components will never reside in such a directory. A Unix file cannot exist that is not registered in some directory. Objects may exist in capability systems, with capabilities designating them without those capabilities appearing in any directory.
An analogy between capabilities and pointers is instructive. A pointer designates a computing object. A pointer is not protected however and bit patterns not intended as pointers cause havoc when so used. Java has protections against such misuse and consequently Java’s object references serve as capabilities. (Some more quibbling about names and capabilities.)
Registering application components in Unix directories often exposes them to programs and people that should have no access to them. Most computer users have been faced with directories holding large and expensive objects with little way to learn the consequences of deleting them to recover space. Many applications have failed because the machine administrator could not tell what files were necessary to some critical application.
The application within a capability system appears to the computer administrator as a single object of known size with no parts. We designed, but did not implement for Keykos, controls so that a subsystem upon which an application depended could not be deleted without the authority to delete the application.
If there are no calls, whither the stack?
Capabilities often designate storage objects such as pages and segments. Such things are not normally thought to be receiving and sending messages. It is constructive to describe them this way, however.
In this light the operations that a capability is said to support in other modes of description, may instead be explained as merely some data in the message that the receiver interprets which is the most meaningful part of the message.
Sometimes we say that there are distinct capabilities to the same object. Joule calls these “facets”. The object is able to discern thru which facet a message arrives. The same situation can alternately be described by saying that the facets are to different objects that share the state of some larger object.
This section needs cleaning and repositioning!!