Split Capabilities: Making Capabilities Scale

[Mark S. Miller]

At 11:11 AM 7/6/00 , Karp, Alan wrote:
> > First, let's be clear that "I" is a program, not a user. It 
> > is very easy for
> > programs to track what capability goes to what. When was the 
> > last time a
> > production version of a program you ran got its file 
> > descriptors confused?
>
>It's still a piece of code I have to write, debug, and maintain.  Also, how
>does my program determine which object a capability is referring to?  If I
>get my capabilities from an authentication server instead of the object's
>owner, there's no obvious way to make the connection.

In a conventional capability system, the capability *is* the designation of 
the object it refers to.  Think of an object reference in Smalltalk or Java. 
How do we know what object it refers to?  Well, there's no more meaningful 
answer than "the object that this very object reference refers to."  Sorry, 
I know that isn't very satisfying, but I don't see that there's any other 
answer available or needed in Smalltalk or Java.  Turn object reference into 
capability, and we have the same situation in E.

Or, one can answer by computational history: "This is the object reference I 
received as the third argument of the 'foo' message I'm currently 
processing."  Or "This is the object reference my creator endowed me with as 
my 'zippy' instance variable."  This notion of "which object" corresponds to 
the lambda calculus use of naming, or the capability operating system use of 
clist indexes.  It names not a particular object, but that object that has a 
particular relationship to the current object.  Again, it seems to me that 
E-speak's naming system has a very similar perspective, so I'm puzzled about 
why you're puzzled.


         Cheers,
         --MarkM