[cap-talk] Objects and Facets

[David Hopwood]

Charles Landau wrote:
> At 5:56 PM +0100 8/3/06, David Hopwood wrote:
>>Neal H. Walfield wrote:
>>
>>> I understand the terms object and facet in the following way: an
>>> object encapsulates some state which can be sensed or manipulated
>>> through capability invocations; a facet presents an object with
>>> diminished authority, e.g. a read-only facet.
>>
>>My understanding is that the facet pattern
>>(http://c2.com/cgi/wiki?FacetPattern) is a particular simple kind of
>>authority diminishment, in which the facet presents a subset of the
>>interface of the object to which authority is to be diminished.
> 
> This definition of facet in terms of an object interface raises the 
> question, what is an object?

Each object capability system defines what it considers to be an object,
and what it considers to be a capability, subject to the following
constraints:

1. a capability unambiguously designates a single object;
2. objects may hold capabilities to other objects;
3. in general, an object may have mutable state;
4. an object may be invoked by another object having a capability to it,
   and not otherwise;
5. invoking an object causes it to act on a message specified by the
   invoker. The invoker may specify capabilities it holds that are
   transferred with this message to the invokee;
6. an object may create a new object X with a specified behaviour and
   initial state, optionally transferring capabilities it holds to X,
   and obtaining a capability to X;
7. in a running system, the only ways for an object to obtain additional
   capabilities are as specified in points 5 and 6.

Password capability systems, where each capability is represented by a
password, satisfy a weaker version of point 7:

7'. in a running system, an object may only obtain additional capabilities
    by gaining knowledge of their passwords, and *the system* only transfers
    passwords according to points 5 and 6.

> Neal and many others associate an object with some state. Consider 
> then a stateless capability such as the Discrim key in KeyKOS 
> (http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Gnosis/43.html#discrim) 
> and EROS (http://www.eros-os.org/devel/ObRef/kernel/Discrim.html). 
> Does it refer to an object?

Yes. It is obvious that in any system where objects have mutable state,
a special case is that the state is constant.

> My belief is that while the term "object" is a wonderful informal 
> concept, it has no formal definition. Consider a start key to a 
> process implementing an Ethernet socket. From the kernel's 
> perspective, the start key is a facet of a process object, and an 
> invocation of the key just delivers a message to the process.

In terms of the object capability model, in this kind of system a
process implements multiple objects. There's no obstacle to formality
here.

> From a higher perspective, the object is the socket service, and an 
> invocation of the key sends a message on the socket. From a yet 
> higher perspective, the object is something on the other end of the 
> socket, and an invocation of the key sends a message and receives a 
> response from that thing.

In this situation there are two capability systems, a local one and
a distributed one. In the local system, there is a socket object; in
the distributed system, there is a remote object. The socket object
is part of the implementation of the remote object in the distributed
system.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>