[cap-talk] Re: Capability development principles - "no copy" seen as wrong

[David Hopwood]

Jed at Webstart wrote:
> At 12:51 AM 11/29/2005, David Hopwood wrote:
>> Jed at Webstart wrote:
>> > At 10:19 PM 11/25/2005, Rob J Meijer wrote:
>> >
>> >> At the risk of sounding stupid, I've always kinda understood that
>> >> being able to 'transfer' a capability , itself is also a capability.
>> >
>> > I don't see how the above can work.  Doesn't it set up an instant
>> > infinite recursion?  That is, if C is a capability and let's say that
>> > T is the capability to transfer C, then there must be a capability
>> > to transfer T = TT, and so on.
>>
>> Yes. Why is this a problem? It doesn't mean that there must be infinitely
>> many capabilities in a system, provided that for each C, T^n_C =
>> T^(n+1)_C for some n.
> 
> As I understood the premise, for every C there is no n for which T^n_C =
> T^(n+1)_C
> because T^n_C merely supplies the permission to copy T^(n-1)_C, while
> T^(n+1)_C provides the permission to copy T^n_C.  These are clearly
> distinct permissions and so cannot be equal.

They are not by definition the same, but they can be equal in some cases.
It is quite possible for the capability that (directly) grants the ability
to copy a particular X to be X itself.

> I admit this is somewhat nit picking.  However, I can't tell you how bad an
> ideal I think this basic approach is - at least in this short message ;-)

I agree that it is a bad idea. I was just trying to point out that the
specific criticism above isn't valid. If it were, then it would also
make impossible finite reflective systems in which each object has a
metaobject, or (as in Smalltalk, for example) each class has a metaclass.

> Still, as usual I will try:
> 
> I view the ability to communicate a possessed capability as an indivisible
> and indispensable property of the capability as a token of permission. 
> While there
> is indeed a very long history of efforts to provide copy restriction as
> a putative added value, in my opinion all such efforts have turned out
> to be counter productive - at least in the sense of wasting mechanism
> and providing no added value, but most often in terms of significant
> additional complexity and mechanism that results in confusion and
> binding constraints on the system whenever such a feature is used.

Agreed.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>