[Cap-Talk] Request for comments on Hanson Goo

[David L. Nicol]

Johan Hanson wrote:
> 
> I would like to get opinions on my model from people who are more
> experienced with capabilities. A draft paper has been posted at
> http://gooey.sourceforge.net/cap.html

In which is found:

> Capability Tree
> 
> There are two types of capabilities - Handles and Tickets. A Handle can be
> used for all purposes but can not be passed between
> processes. Tickets can be passed from one process to another,
> but can only be used for sending messages, can only be used once and is
> only valid during a limited (implementation-defined) time period. The
> propagation of the Capabilities to a specific object form an
> conceptual tree with Tickets as the branches and Handles as the nodes
> and leaves. 

I liked the definition of a "capability" as a "a reference to an object
with bundled access rights valid for that object, and that object only."

I do not understand why you are subclassing these things into Handles
and Tickets however.  One of the advantages of Capabilities over, say,
"stream handles" is that you can abandon the process model, because
the capability contains all info required to interact with the object.

So my opinion is, you could rearrange your object hierarchy so that the
handles and tickets use a has-a relation rather than an is-a relation
with regard to the capabilities.  I assume the "handle" will  
eventually act something like a stream.  Maybe you can promote a 
capability to write to an object into a handle to that object, which you
can shift data into, after you activate the handle some how.


So that's my suggestion: consider hasa instead of isa for the relation btn
handles|tickets and caps.


-- 
                                           David Nicol 816.235.1187
      Series EE bonds can be exchanged for Series HH savings bonds.