[cap-talk] kernel object knowledge

[David Hopwood]

Peter Amstutz wrote:
> One aspect that may be lost in the discussion of whether the "kernel" 
> understands the underlying capability model is that it is useful for the 
> capability descriptor itself have a uniform model -- if I have a 
> capability for an object, want to know if I can call certain methods or 
> not.  I also want to be able to store the capability descriptor 
> efficiently, and to be be able to serialize the capability descriptor to 
> persistent storage.  It's not helpful to me to get an object capability 
> back that appears to let me write to an object but actually silently 
> drops all write requests.  I'd rather than the system be able to tell me 
> exactly what methods are permitted with a certain capability, and to 
> give back a uniform "you can't do that" error if I do step out of 
> bounds.
> 
> From an efficiency point of view (as well as the extra work of 
> reflection) I'm a bit uncomfortable with the E approach, whereby you 
> create a restricted capability by defining a new class and a new object 
> that isn't obviously connected to the underlying object without doing 
> some degree of introspection.  I like the idea of being able to point to 
> a simple bitfield that tells you which methods are permitted for a given 
> capability.

The following:

 - whether there is a facility to determine if an object implements a
   particular method selector or not (~= Smalltalk "respondsTo:")
 - whether you can store a capability descriptor efficiently, and write
   it to persistent storage
 - whether a restricted facet silently drops disallowed requests or
   reports an error / throws an exception
 - whether restricted facets are implemented as separate objects, or
   built into underlying objects

are all somewhat independent.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>