A capability designates some one object. We invoke a capability by sending a request via that capability. Normally a response is subsequently delivered to the invoker. Requests and responses are messages. To invoke an object is to invoke a capability to that object. In the case of Java, or its predecessors, we consider the method name as part of the request and the type of any exception thrown, as part of the response.
Ideally:
Alas it is more complicated than the above but the above is a good place to start.
The state of object X may include a capability to yet another object Z. The behavior of X may include invoking Z. The message invoking Z may depend on the state of X and the response from Z may effect the subsequent state of X. To fit the above ideal it is necessary to include the state of Z in the state of X. Objects X and Y can both include the same capability to Z. Now the third ideal principle is violated for an invocation of X may change the state of Z which belongs to the state of Y!
There may be several capabilities to the same object. We will call these facets of that object. We could document the situation of the previous paragraph as follows: Capabilities X and Y are two facets of the same object. In Keykos, E and Joule, facets are provided in the foundation which means there may be distinct capabilities to an object implemented in the foundation. In Java however, references to a particular class instance are all the same. The effect of facets may be had, however, by another layer as described above.
Whether objects are actually implemented in layers, as above, and whether they are documented that way, are entirely independent issues. It is an important flexibility that the documentation not constrain the implementation. Keykos does not allow the holder of capabilities X and Y to determine whether they designate the same object.
Alas it is yet more complicated in Keykos at least. The above would suggest a strict pairing between requests and responses. Yet more general patterns are possible and very useful. This gives the rules fairly concisely, where “key” means capability.
See this for Markm’s resolution of the facet issue.
I fear my pages will remain confusing on this point.
Here is some old but clarifying email:
2006-08-07,
2006-08-07,
2006-08-08.
Markm recently proposes a one to one map between caps (or keys or capabilities) and objects and a many to one map from objects to subjects. The object is the finest subdivision of authority provided by some system state whereas the subject is the smallest unit that holds authority (in the form of caps). In this terminology the Keykos domain is a subject. Objects serve as facets to a subject. Keys with different data bytes but to the same domain are then ‘to different objects’. The objects (each with differing behavior) share a subject (with its own state). The state of an object is that of its subject. This is quite logical but I think these pages will not soon convert to that terminology.
When I have been careful I use ‘key’ where Markm uses ‘object’ and I use ‘object’ where Markm uses ’subject’. We agree that nodes have slots and a slot, at some moment, holds some key.