Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Wednesday, July 26, 2000 1:13 AM
> To: Norman Hardy
> Cc: Karp, Alan; 'Dan Bornstein'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 09:05 PM 7/25/00 , Norman Hardy wrote:
> >The increment facet of the updown counter may be delivered to the car
> >counting agent at the garage entrance ...
> 
> I love this example.  However, Alan's objection that 
> "increment" is a more 
> informative message name than "do" still applies so far.  
> First, I'd like to 
> make clear that my example was not intended as an example of good 
> programming style, but a demonstration of a case that can 
> occur in any of 
> the capability systems under discussion.  Programmers cannot 
> be forced to 
> give their programs meaningful message names.

The message name "increment" is no more meaningful than the message name
"do" to someone who does not speak the language.  I used the term
"decrement" as something that Werner von Braun could interpret as reducing
the state variable by 1.  The actual name is irrelevant.  I could just as
easily have said "do", but then I would have had to explain the resulting
state transition.

My point was that I can reason about the object only if I know how its state
is allowed to change.  Herr von Braun believes that a counter initialized to
10 will reach 0 before he decrements it 11 times.  (It may be less than 10
times because someone else may also be decrementing the counter.)  If the
counter does not reach 0 before the 11th decrement, von Braun will be
puzzled unless he knows that there are operations that can increase the
value of the counter.

This gets back to a comment in my earlier note.  An object is state plus
behavior, but behavior is not the same as interface.  I believe that
interface is simply one way to describe behavior.  Hence, I can reason about
a facet as an object if I know the object's behavior.  I don't need to know
its interface.

> 
> If the consider the two ActionListeners above as two facets of one 
> composite, then it's clear that they map the same 
> message-name/order-code to 
> two different behaviors.  In KeyKOS, EROS, Joule, and E, 
> these facets can be 
> forseen (I don't know about Droplets or the E-speaks).  In 
> KeyKOS and EROS 
> they can be two capabilities (using two different data-bytes) 
> on the same 
> domain.  

E-speak uses dispatch tables to map method invocations.  However, any client
can request any method.  Whether or not the request gets satisfied depends
on the capabilities presented.  In e-speak DR 3.0, these capabilities are
certificates listing the allowed methods and map quite naturally to facets.
In e-speak Beta 2.2, the capabilities are resources that the engine uses to
extract strings that the object interprets as permissions.  The effect is
the same as facets, but I doubt that anyone would come up with that term
from the description of how things are done.

> 
>			(snip)

         Cheers,
         --MarkM


_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278