• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] In reply to: Paul Snively

> > Obviously, the intent of the two is quite different...
>
> It is? I'm not sure I understand how: the intent of both is to provide
> access to computational services. The only significant
> difference that I see is that with traditional RPC, security
> is an "external" consideration,
> whereas with capabilities there's an "intrinsic" security
> model (although as always, it's worth pointing out that in the capability
model,
> if you have a capability, you have it, and that's that. The crucial
> question is: how did you come by that capability?)

Ahh. That explains the distinction I felt but couldn't articulate well.

> I think it's fair to say that a distributed capability system *is* a
> distributed object system. Certainly the E platform
> (<http://www.erights.org>) is.

This is very interesting. Some year ago, I did some work on a distributed scheme, and some of the concepts seem very similar. The most appealing thing for me in the distributed scheme was that objects, because of the lexical scoping of scheme, could only talk to objects within their scope. This removed a number of security issues, and also made writing distributed objects/applications easier... the objects could be written like objects, not stateless servers.

I guess in a distributed scheme, you could look at every lambda as an anonymous capability?

It seems to me that there must be some very interesting relations between capabilities and type composition.

[ Next ]
• [ Previous ] In reply to: Paul Snively