[cap-talk] the prize - objects and their behavior, EQ?

[Charles Landau]

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:
>
>http://www.webstart.com/jed/papers/DCCS/
>
>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.