On Wed, 2005-10-19 at 12:10 +0100, Neal H. Walfield wrote: > At Tue, 18 Oct 2005 14:27:56 -0400, > Jonathan S. Shapiro wrote: > > I believe that the only possible protocol that could be correct is for > > all object servers to return by way of CapServer. In practice, this > > makes locally trusted CapServers impossible, because a general-purpose > > server cannot make assumptions about how the objects it creates will > > later be transferred. > > I'm having difficult understanding this paragraph. > > What does "return by way of CapServer" mean? Does it mean that when a > server returns, it doesn't respond directly to the caller but has the > capserver respond to the caller?
Yes. > > Why types of assumptions can't a server make about how the objects it > creates will later be transferred? Do you mean, for instance, if a > server uses the cap server any client must also use the cap server to > transfer the capability? I don't think this example is true as a > client can still provide revocable mappings. TERMINOLOGY CHANGE: I will explain in my next mail, but I am going to start using the term SIMULATED COPY to describe our implementation of COPY using the capability exchange server. The problem is that I have realized that the cap server just doesn't work at all, so I want to start distinguishing the two clearly. More on this in a moment. I do not mean that a client cannot use REVOCABLE COPY. I mean that if any client *ever* wishes to perform a SIMULATED COPY, then the CapServer must have a non-revocable capability. Since an object server cannot know how a receiver will use its capabilities, it must unconditionally return via CapServer in order to ensure that SIMULATED COPY is later possible. Note: this doesn't work, and I know it doesn't work, and I am about to explain why in my next note. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
