[cap-talk] the prize - objects and their behavior, EQ?
clandau at macslab.com
Fri Oct 22 00:21:01 EDT 2004
At 9:11 PM -0400 10/21/04, smagi at naasking.homeip.net wrote:
> > The RATS system was a virtual memory system and had
>> a file object with the usual reading and writing operations.
>> However, there was also a call on a file object that allowed
>> a process to "map" a portion of a file into its memory space.
>Doesn't this violate capability discipline anyway? The process is
>designating itself implicitly rather than explicitly in this "map" call.
>Doesn't capability discipline demand that all rights wielded in any
>operation be explicitly named?
Guilty as charged. This was an error, and it was inadvertent. At that
time I had only been working with capabilities for seven years. I
agree it illustrates Jed's point about the value of thinking in terms
of "network discipline".
At 2:28 PM -0700 10/21/04, Jed Donnelley wrote:
>One need not go fully to a network communication mechanism
>for object access rights to achieve the "network discipline" that
>I am arguing has important value. I believe it suffices that
>all object accesses support what I referred to in:
>as the "insertion property" - terminology adapted from:
>F. A. Akkoyunlu, et. al., "Some Constraints and Tradeoffs in the Design
>of Network Communications," Proceedings of the Fifth Symposium on
>Operating System Principles, 1975, Vol. 9, No. 5, pp. 67-74.
>I don't see any recent uses of that phrase in a Google search.
>Perhaps there is a more modern term for this concept?
I believe this is now called "transparent proxying".
>At 04:37 AM 10/19/2004, Jonathan S. Shapiro wrote:
>>I would be very interested to hear Jed's thoughts on how EQ? should be
>>defined between proxy capabilities and local capabilities.
>I don't fully understand what you are getting at with regard to the
>notions of "EQ" that you refer to. I think Charles Landau started
>to address some aspects of EQ in a later message. For comparison
>you might find it relevant to compare the "equality" operations that the
>Distributed Capability Computing System needed. It needed:
>1. The ability to compare two capabilities (in its case in a processes
>c-list) for absolute equality (i.e. the pointed to the same object,
>with the same rights, served by the same server),
This is the "eq" operation that I understand Jonathan to mean. In E
it's called == or Same.
>and 2. The ability for a process that has created a proxy (extended)
>capability to determine whether a capability was one of the capabilities
>that it itself services, and if so which one.
As I've hinted before, this can theoretically be built using only "eq".
>C. What's "wrong" (i.e. inadequate) about having objects
>defined entirely by their behavior in response to messages?
What's wrong is simply that it fails to support your requirement #1 above.
Capabilities can be used in only two ways. You can send a message to
the capability, or you can pass the capability in a message. "Defined
entirely by their behavior in response to messages" means that you
cannot gain any information about a capability simply by passing it
in a message. "eq" gives you information about a capability when you
pass it, without invoking it.
More information about the cap-talk