[cap-talk] Objects and Facets

[Jed at Webstart]

Terminology,

I have to admit that don't follow some of the nuances of this discussion.
For me what it comes down to is:

At 07:02 PM 8/6/2006, Charles Landau wrote:
>...
>The only formal reality is capabilities and processes.

capability = reference
process = active object in a "domain" (is a domain?)
object = whatever a capability/reference permits access to

This:

At 05:19 AM 8/7/2006, David Hopwood wrote:
>...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.

sounds reasonable to me.  I think it important to use the terms
"capability" and "process" (active object) for the highest level of
abstraction - allowing multiple implementation and possible
translations.

Regarding a list like David supplied (below with comments), I'm
not sure what value such a list provides except perhaps for
guidelines/examples.  To me any attempt at formalism through
such a list is unwisely constraining.  I hope my comments
will suggest why I feel this way:

At 05:19 AM 8/7/2006, David Hopwood wrote:
>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;

I don't understand what the above contributes.  How could it
be otherwise?  Isn't the object by definition that which the
capability grants permission?

>2. objects may hold capabilities to other objects;

Again I don't see the value.  Certainly active objects (processes)
may hold capabilities (to other objects - again redundant), but
what does the above add of value?

>3. in general, an object may have mutable state;

This needs to be stated?

>4. an object may be invoked by another object having a capability to it,
>    and not otherwise;

This one above seems to me the essence of what a capability is.
A capability is a token granting a permission.  Since it does so
there must be some means to yield that permission - an "invocation".

Unsaid here but I think implied (certainly desired for confinement) is
the notion that no permissions outside a process are available except
through capabilities.

>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;

Of course the invocation, being the means for yielding the permission,
must allow some action to take place.  Considering that in the context
of a "message" seems reasonable to me.

The important aspect of this #5 seems to me to be the idea that
permissions as "capabilities" can be delegated through an invocation,
communicated.  Combine #4 and #5 and it seems to me you have the
essence of the object capability model.

>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;

The above need not be true and to my thinking adds an unnecessary
constraint.  It need not be true because it is only by way of some other
capability the permission to create a new object is conveyed.  An
object (process) without such a capability won't be able to create a new
object as above.

>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.

I view as counterproductive efforts to define a dichotomy between
implementations of capabilities, some as protected references and some
as data, including but not limited to "password" capabilities.  In so far as
they strive toward the object capability model (including 
delegation), capability
implementations are just that - efforts to provide the safest and 
most efficient
implementation of the model in a given context - e.g. within a shared memory
SMP, within a language, across a network.

I believe such efforts at categorization and separation (one might
say "discrimination" ;-) could be better spent in defining standards,
means of translation and communication across implementations.

I believe those working in the capability communication field most
often start creating problems if/when they start to think that they
can do things with their implementation that aren't possible in
general - such as blocking delegation between cooperating
conspirators as we've discussed recently on this list.  I put
into that same category any capability implementation that
can't be extended to a network, usually because it can't support
the "insertion property" (invisible proxying - e.g. across a network).

--Jed http://www.webstart.com/jed/