[cap-talk] Another "core" principle

[Marc Stiegler]

Man, spend a weekend with the family, give up all hope of figuring out 
what is going on. I am going to comment on 2 excerpts from shap's 
emails, on the off chance I am replying to something that needs a reply.

Jonathan S. Shapiro wrote:
> I propose the following as a core principal:
> 
>   3. We must not accept any design pattern for authority management
>      whose use cannot be managed by human beings in the real world.
> 
> I'm not sure my concern is valid, but I'm concerned about the membrane
> pattern. If the consequence of causally dependent capabilities (which is
> what membranes build) is that nobody ever dares to revoke a membrane,
> then there is absolutely no point introducing the membranes in the first
> place.
> 
> If my concern proves to be valid, then the membrane pattern should be
> rejected -- even if we can make it work from a technical perspective.
> 
> shap

And earlier shap wrote
Jonathan S. Shapiro wrote:
 > Okay, now for some *real* fun... :-)
 >
 > On Sat, 2006-12-16 at 23:00 -0500, Jonathan S. Shapiro wrote:
 >> Get serious! We are talking about fine-grain, capability-connected
 >> object structures here. Even if there was a tool to audit the structures
 >> and offer to replace the capabilities sensibly (a tool we probably
 >> should NOT build, for reasons given below), Alice has absolutely no clue
 >> what any of these pointers mean, what they connect, or where she got
 >> them from (Bob's delegations may go back for years). Losing the
 >> structures isn't an option -- the data structures contain critical state
 >> that commingles capabilities and data from ALL of the members of the
 >> group.
 >
 > There is an overriding problem hiding in here: causal connectivity
 > tracing is FAR too strong, and recovery from causal revocation is
 > pragmatically impossible.
 >

These are two passages concerned with the theoretical (never observed in 
anything I have seen or written) problem of fine grain caps getting so 
intertwined that you dare do nothing but leave them alone.

To quote a book that I myself wrote: "The engineer takes a large problem 
and breaks it down into small problems, each of which can be solved 
easily. The bureaucrat takes a large number of small problems and rolls 
them all together into a problem that no one can solve."

Preventing incomprehensible intertwining is what modular design is all 
about. Using the logic that finer-grain control means understanding of 
what is going on, one would predict systems build of tiny objects to be 
incomprehensible, and less maintainable, than systems built using 
FORTRAN, which encourages monoliths. Obviously, however, the opposite is 
true. Module design involves not only breaking things into small pieces, 
but also assembling them into compositions, which can also be understood 
easily. Caps, which flow so naturally from objects, follow the same 
logic to the same conclusion. All of which probably has something to do 
with why I haven't seen a problem in the field.

A similar observation which I feel obligated to point out is, for me to 
revoke a membrane upon which you might be depending is a perfectly fine 
thing for me to do. What you need is not for me to be locked in stone 
(well, you might like that, but it is not an option, whether we are in 
cyberspace or physical space). I am going to protect my interests. What 
you need is a way to protect your interests. In other words, we need 
machinery that enables us to write software that minimizes plan 
interference between thee and me. As it happens, there was a 
dissertation by a promising young student recently, demonstrating that 
the combination of caps and vats allows one to reduce plan interference 
in comparison with traditional techniques. By reducing plan 
interference, and by putting you in charge of your interests, I am more 
able to revoke my membranes, not less.

--marcs