Split Capabilities: Making Capabilities Scale

[Norman Hardy]

At 9:21 -0700 00/07/27, Karp, Alan wrote:

...

>That's the problem I have with thinking of facets as objects.  There are
>state transitions in the interface to a single object that affect my program
>that I'm not aware of because they don't appear in my facet.  I'm not saying
>that I need to know all possible ways that the count can be incremented; I
>only need to know that there is a method that increments the count.
>

If you are writing the real time code that responds to tire presses as cars
pass, you do not need to know the greater ramifications of invoking the
incrementer or decrementer. Indeed you don't need to know whether they are
comming or going. Someone else needs to know, granted.

On the otherhand:

That rings a bell. I worked at IBM not very near sales but near enough to
understand that IBM wants a single IBM salesman to control all interactions
between IBM and some particular enterprise customer of IBM. IBM had a very
thurough theory of such things. Among other things this keeps different
parts of IBM from competing to sell to the same requirement withing the
enterprise. IBM at least wants to retain what advantages there are to being
one company rather than many.

Another obscure but important failure in abstraction was when Tymnet bought
"diversly routed" circuits from the phone company to connect out network
together. Even though the circuits were diverse at one abstraction level
they were not at another. The phone company itself didn't know how to
provide this. The phenomenon is called "common failure modes" which foul up
abstractions. The "diverse" circuits would fail simultaneously due to one
high capacity link going out, several levels deep in the scheme.

I think that it may be necessary to speek of agenda to tease apart our
differing perspectives. I mean the agenda of the application programmers
and their programs, not the platform designers.
I am not prepared to do an essay yet so I will ramble briefly.

To what purpose is the computer executing some obscure routine just this
instant? Well it is taking a square root, but the reason for taking that
root is to be found in the state of the routine that called it, etc up to
the top which may be to compute the orbit of some planet. This provides a
hierarchical view of all parts of the execution of an application. The code
the performs Runge Kutta iterations need know neither about taking square
roots nor about orbits. Separation of concerns. In B2B applications, agenda
of two parties may be interacting withing one computation. Part of the
resistance to capability discipline is the inability to imagine two such
differing agenda within the same computing system. It is normally thought
that at least a TCP circuit will separate the two agenda. This is close to
but perhaps different from the issue of different interests.
Norman Hardy  <http://www.mediacity.com/~norm>