[cap-talk] Derivative rights
jed at nersc.gov
Mon Feb 4 21:30:48 EST 2008
On 2/4/2008 5:43 PM, David Hopwood wrote:
> ross mcginnis wrote:
>> This is the crux of the matter. To me it
>> appears that *any* reference is a cap.
> 'To be sure I was!' Humpty Dumpty said gaily...
Heh. If it's a token that is intended to be
1. It grants access to something via an "invocation"
2. It can be communicated in messages that result
then I would say it qualifies as a "capability"
Of course one of the points of the "object capability"
term is that this notion is very similar to that
of an object reference in an object oriented
A vital aspect of a capability is that both the
designation (what sorts of access operations the
capability provides) and the authority to carry
out those operations are bundled into a single
"token" that can be communicated in a capability
Now perhaps we should consider references that
1. A pointer in C isn't a capability because
it can be forged (in C).
2. mysystem:/etc/shadow isn't a capability
because it isn't bundled with the authority
to operate on the designated object.
isn't a capability because it isn't bundled with
the authority to operate on it (e.g. read or write)
4. On the other hand, this:
is a capability, because it's designation comes
bundled with the authority to operate on it.
5. Of course this:
Dennis J. B., and E. C. Van Horn,
"Programmed Semantics for Multiprogrammed Computations,"
March, 1966, Communications of the ACM, Vol. 9 No. 3,
isn't a capability because the designation isn't
bundled with an authority to operate on it.
Of course there are nuances, but I hope the above
clarify that at least not all references are
capabilities. If you restrict your use of
the term "reference" to object references in
OO languages, then I think that is pretty close
to what a capability is - except for the safety
(non forgeability) issue, e.g. the reason for the
Joe-E subset of Java.
More information about the cap-talk