[cap-talk] Objects and Facets

Jed at Webstart donnelley1 at webstart.com
Wed Aug 9 15:00:59 EDT 2006

At 10:45 AM 8/9/2006, Norman Hardy wrote:

>On Aug 8, 2006, at 5:49 PM, Jed at Webstart wrote:
> > At 08:31 AM 8/8/2006, Norman Hardy wrote:
> >> Both of our descriptions need additionally to specify that the three
> >> returned capabilities provide the only access to the state.
> > I'm not sure whether it would even be appropriate to do so.  What about
> > the server itself?  Are you arguing that it doesn't have access to these
> > services?  What about the owner of the system?  Suppose new capabilities
> > are created that provide the same permission?  Are the old capabilities
> > any less "capabilities" because there are new means to these ends?
>I am saying just that. See <http://cap-lore.com/CapTheory/NewStyle>
>for agonizing over whether this is wise.

Hmmm.  As I read it (e.g. summarizing) as:

"omits description of the many internal registers used to make the machine
run faster, and speaks only of those registers whose contents are relevant
to the meaning of a program"

this is something different.  I'm not concerned about the internals so much
as the externally viewable behavior.

For example, in the case of the counter, if I create a new counter, initialized
to 0, and then I increment it once, I expect to get the value one (1) 
when I read it.
If somebody else has increment permission to the counter (an increment facet),
then I could see any value greater than zero.  The external behavior 
is changed.

Using capability access graphs to reason about the limits on observed states
seems quite a reasonable thing to do to me.

I only wanted to note that whether this sort of limitation is extant 
or not (e.g.
if such a counter capability has been widely shared), the token of permission
is still a "capability".  The object services are free to make their "objects"
(visible through capability invocations) appear any way they like.  One sort
of behavior vs. another doesn't make the permission tokens any less
"capabilities" - though it could make the capabilities more or less useful.

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

More information about the cap-talk mailing list