Split Capabilities: Making Capabilities Scale

[Mark S. Miller]

At 03:03 PM 7/26/00 , Karp, Alan wrote:
> > From: Eric Messick [mailto:eric@syzygy.com]
> > ... the person who
> > programmed "von Braun" *does* know about the existence of the
> > increment operation and has coded "von Braun" appropriately (what ever
> > that might mean).
>
>That's what I was hoping that MarkM would say, that the programmer of the
>von Braun object knew about behaviors not represented by facets held by the
>programmer who delegated them to von Braun.  I took his statement "No
>automatic awareness provided." to mean that this was not the case.  Without
>such knowledge, the programmer may not be able to code a correct von Braun
>object. ...

At 02:33 PM 7/26/00 , Ken Kahn wrote:
>... But in an open system
>where programs communicate over trust boundaries there are inherent
>limitations about how much you can reason about the system behavior. ...

At 03:13 PM 7/26/00 , Karp, Alan wrote:
> > I suspect there are some unspoken assumptions about the 
> > overall context in
> > this discussion of facets. Who is hiding side effects from who?
>
>No one.  Whoever decides that I get to see only a facet that reveals less
>than the full behavior of the object is hiding from me state transitions
>that I interpret as side effects.

Milton Friedman says:
 > No one knows how to make a pencil.

I'm with Ken, and I'm not saying what you hoped I would say.  (I also doubt 
Eric is actually saying what you hoped I would say, but I'll let him handle 
that.)  As a programmer, when I program object A to use services provided by 
object B, I usually do so without being aware of the transitive closure of the 
side effects that will result from my interactions with B. Also, I often do 
so without being aware of the transitive closure of side effects from others 
on B that may effect the answers I get from B. However, to the extent that 
B's interface contract is documented, I can program A correctly by only 
relying on documented properties of B. As long as A discharges its 
contractual obligations while only counting on the services it uses (B) to 
discharge their obligations, then A is correctly coded, even if it's coded 
in ignorance of B's transitive side effects. (This description assumes that 
A may correctly rely on B to do what it is supposed to.  In a system 
supporting mutual suspicion, this is often not the case, but that's a 
separately analyzable matter.)

To use one of your favorite examples -- printing a page on a printer -- 
probably no one ever has had a complete account of the transitive side 
effects of this partly physical action.  If the printer runs out of paper, 
it may light an alarm causing someone to refill it and order more paper, 
causing a P.O. to be issued to a paper company, causing the paper company's 
EJB inventory system to crash.  The transitive closure of my effects on the 
price of paper effect the entire economy. Does this prevent anyone from 
printing on a printer correctly?  No.  As someone issuing a print command, I 
don't and shouldn't care whether the paper company's EJB inventory system 
works or whether the price of paper effects the price of tea in China.

I suspect that somehow we are arguing terminology rather than substance 
again, as it's hard to believe that the above description is not equally 
true of the E-speaks.

Ironically, some of the systems I have in mind -- KeyKOS, EROS, Joule, and 
E -- are almost unique in the world at providing A the ability to 
insist on constraints on the transitive side effects of objects it uses -- via 
confinement.  For an observably confined B, A can indeed know where the 
transitive closure of side effects stops (modulo wall banging).  But this is 
and should be a special arrangement.

At 03:13 PM 7/26/00 , Karp, Alan wrote:
>We have a similar problem in e-speak which we resolved by providing the full
>interface on request if authorized.  I recently decided that all that's
>really needed is a formal description of behavior.  Of course, I don't know
>how to write such a description, but that's OK.  Smart people can figure it
>out.

If you mean a machine understandable description, no they can't.  A lot of 
smart people have tried and failed.  The only complete description *in 
general* of the behavior of an object is the code (and state) implementing 
this behavior, as well as the transitive closure of other objects that may 
effect or be effected by this object.  Even this would not tell the 
programmer of a client of the object which properties of this behavior were 
intended vs incidental.  Without this distinction it's impossible to write a 
correct client.  

Actual practice is that interface contracts are often 
human-only-understandable decorations on interface types.  Rarely is the 
entire contract even spelled out in natural language.  Most of it is usually 
in the folklore in the community surrounding the use of the interface.  I'm 
not advocating this, just observing.  I also don't imagine that creating a 
new platform (any of ours) will do much to change this practice.

So if you don't know how to write such a description, what did you provide 
on request?  Whatever that is, how is it different in kind from an alleged 
interface type?  How may A's (or von Braun's) programmer use this 
description to know whether the side effects include Chinese tea prices?


         Cheers,
         --MarkM