Mark and I spent the day together yesterday to try to understand why we say the same thing so differently. As with most such disagreements, the difference lies more in the model than the mechansims. Most of you guys are coming from a language and/or operating system perspective. We were heavily influenced by corporate IT environments.
It took a couple of hours of intense discussion with Mark, but we finally figured out the central point of confusion. First of all, e-speak Beta 2.2 uses split capabilities; e-speak Beta 3.0 does not. In e-speak Beta 3.0, the capability contains access rights and a reference to the object; the handle for the object is distinct. In addition, you may be getting your e-speak capabilities from a different place, say a centralized LDAP repository, than the source of the object handle. Hence, in e-speak a means to associate the handle for the object with the capabilities that refer to it is needed. In E, the capability IS the handle to the object; there is no possibility of confusion. In addition, an E capability is only a bit larger than an object reference; an e-speak Beta 3.0 capability is a SPKI certificate that may contain a long chain of delegation. Hence, in E you're not using up a lot of extra resources per capabilty; in e-speak Beta 3.0, you are.
With split capabilities in e-speak Beta 2.2, the capability is independent of the resource; it may be controlling an access right to a large number of resources. It is also extremely lightweight, being just a resource reference itself. Hence, split capabilities have a number of advantages over SPKI certificates as capabilities. Their justification is weaker when compared to E.
So, the question is, Was this discussion just a rat hole, or is the idea of a split capability useful for E?