[cap-talk] Objects, Facets and Capabilities

[Charles Landau]

At 5:20 PM -0700 8/2/06, Jed at Webstart wrote:
>At 05:23 AM 8/2/2006, 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.
>
>I see that some have used the term "facet" in the above way, e.g.
>the sub thread that starts here:
>
>http://www.eros-os.org/pipermail/cap-talk/2006-June/005267.html
>
>I believe the "facet" term is relatively obscure.

I agree the term "facet" is not in common use, but I haven't seen an 
alternative proposed, and I did ask this group.

>Since it really
>only means a particular type of capability and I expect nearly
>any capability can be considered as a "facet" of another more
>powerful capability, the term seems pretty meaningless to me.
>I don't recommend using it, though it seems to show up in
>some of the erights capability documentation.
>
>If anybody wants to defend the "facet" term as meaningful in
>it's own right (necessarily distinct from capability), it seems now
>would be a good time to do so.

I actually agree with you, but I think my view is in the great 
minority. I've hesitated to bring it up here, because it has the 
potential to add confusion, but since you've opened the can of worms, 
I'll respond, and I'll try to be very clear.

Let's give this view of capabilities the name "no facets" so we can 
all be clear when we're using it. In this view, there are no facets, 
just capabilities. This is a "view" because it is just an alternative 
way of describing the system.

Both the usual "facets" view and the "no facets" view say that a 
capability refers to an object. The confusion arises because the term 
"object" has different meanings in the two views.

Suppose Alice has a read-write capability to a file, Bob also has a 
read-write capability to the same file, and Carol has a read-only 
capability to the same file. Alice's capability and Bob's capability 
are different, because they are in different places (Alice can 
overwrite her capability but not Bob's), but they satisfy the EQ 
relationship. Perhaps it would be better to say they are two 
instances or copies of the same capability. Carol's capability is 
clearly different from the others and not EQ to them.

In the normal, "facets" view, all three capabilities refer to the 
same file object. There is a "rights bit" associated with the 
capability that distinguishes the read-write facet from the read-only 
facet. This view is considered natural because it follows directly 
from the implementation.

In the "no facets" view, Alice's capability refers to a File object. 
Bob's capability refers to the same object. If two capabilities refer 
to the same object, they satisfy the EQ relationship, because there 
is no state to a capability other than its reference. A capability to 
the File object permits reading and writing the file.

Carol's capability refers to a ReadOnlyFile object. This abstract 
object contains a capability to the same File object, and proxies 
read invocations, but gives an error on attempts to write. I say 
"abstract" to emphasize that this description describes the 
interface, not the implementation; the actual implementation may, and 
in most cases will, be quite different.

All system implementations support "rights bits" associated with 
capabilities. In the "no facets" view, these bits are simply for the 
purpose of enabling the economical construction of very small objects 
such as the ReadOnlyFile object.

The benefits of the "no facets" view are:

(a) It has the simplest description of capability; it is just a 
completely opaque reference to an object.

(b) There is no need for the concept of "facet".

(c) The description of EQ is simple.

(d) It encourages the separation of the interface description from 
the implementation.

(e) It makes explicit the ownership of the rights bits. They properly 
belong to the object referred to by the capability, not the process 
holding the capability. Some systems (beginning with Dennis and Van 
Horn) have implemented operations that create, from one capability, a 
new capability with some rights bits cleared, without the involvement 
of the referenced object. Such operations violate true capability 
principles, because they unnecessarily expose part of the 
implementation of an object.

The major disadvantage of the "no facets" view is that there is no 
simple phrase that captures the relationship between Alice's 
capability and Carol's. We can't just say that Alice and Carol have 
capabilities to the same file, because in this view their 
capabilities are to different objects.

To respond to Jed's issue above, I think "facet" can be given a 
precise meaning (in the "facets" view, of course). Two capabilities 
are facets of the same object if and only if, in the "no facets" 
view, they are capabilities to two objects, all of whose mutable 
state is shared. The mutable state corresponds to our natural concept 
of object. In the above example, the ReadOnlyFile object has no 
mutable state of its own and just refers to the File object. Does 
this correspond to the way others use the term "facet"?