I've been thinking over RPC, and I've pretty much come into agreement
with Justin on everything he had in mind, but I'll spill that out here
just so we have it in a permanent home (and we can discuss it further):<br>
<br>
1) RPC communication is done through simple Connections and proxy
objects. Connections are like uni-directional sockets. You
don't have to respond to a Connection request with a Connection request
to the source; you might just want one way traffic.<br>
<br>
2) When an object's parent is destroyed, the RPC system reparents it in
some sort of graveyard, and adjusts everyone's proxy objects
accordingly.<br>
<br>
3) Basically, the only methods we need are for the creation of
Connections, and somehow creating proxy objects for those
Connections. In fact, Connection handling methods can likely
exist inside proxy objects.<br><br><div><span class="gmail_quote">On 10/19/05, <b class="gmail_sendername">Justin Hibbits</b> <<a href="mailto:jrh29@alumni.cwru.edu">jrh29@alumni.cwru.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Alright, to make good use of the mailing lists:<br><br>What exactly do we want to provide to a) the user, and b) the developer?<br><br>Adam posted the list of classes we came up with in March, but I don't think<br>it's complete enough, and the behavior isn't fleshed out. So I ask you guys.
<br><br>I don't want a list of classes, I want a set of behaviors that we as an OS<br>provider -- kernel, user libraries, and user interface -- should provide.<br><br>I await your thoughts,<br><br>- Justin<br><br><br></blockquote>
</div><br>