Browsing Chinese (Simplified) translation

550.

You don't have to be a <code class="API" base="twisted.spread">pb.Root</code> to be remotely callable, but you do have to be <code class="API" base="twisted.spread">pb.Referenceable</code>. (Objects that inherit from <code class="API" base="twisted.spread">pb.Referenceable</code> but not from <code class="API" base="twisted.spread">pb.Root</code> can be remotely called, but only <code class="API" base="twisted.spread">pb.Root</code>-ish objects can be given to the <code class="API" base="twisted.spread.pb">PBServerFactory</code>.)

551.

Complete Example

552.

Here is an example client and server which uses <code class="API" base="twisted.spread">pb.Referenceable</code> as a root object and as the result of a remotely exposed method. In each context, methods can be invoked on the exposed <code class="API" base="twisted.spread">Referenceable</code> instance. In this example, the initial root object has a method that returns a reference to the second object.

553.

<a href="listings/pb/pb1server.py" class="py-listing">pb1server.py</a> <a href="listings/pb/pb1client.py" class="py-listing">pb1client.py</a>

554.

<code class="API" base="twisted.spread">pb.PBClientFactory.getRootObject</code> will handle all the details of waiting for the creation of a connection. It returns a <code class="API" base="twisted.internet.defer">Deferred</code>, which will have its callback called when the reactor connects to the remote server and <code class="API" base="twisted.spread">pb.PBClientFactory</code> gets the root, and have its <code class="python">errback</code> called when the object-connection fails for any reason, whether it was host lookup failure, connection refusal, or some server-side error.

555.

The root object has a method called <code>remote_getTwo</code>, which returns the <code>Two()</code> instance. On the client end, the callback gets a <code class="API" base="twisted.spread.pb">RemoteReference</code> to that instance. The client can then invoke two's <code>.remote_three()</code> method.

556.

<code class="API" base="twisted.spread.pb">RemoteReference</code> objects have one method which is their purpose for being: <code class="python">callRemote</code>. This method allows you to call a remote method on the object being referred to by the Reference. <code class="API" base="twisted.spread.pb">RemoteReference.callRemote</code>, like <code class="API" base="twisted.spread">pb.PBClientFactory.getRootObject</code>, returns a <code class="API" base="twisted.internet.defer">Deferred</code>. When a response to the method-call being sent arrives, the <code class="API" base="twisted.internet.defer">Deferred</code>'s <code class="python">callback</code> or <code class="python">errback</code> will be made, depending on whether an error occurred in processing the method call.

557.

You can use this technique to provide access to arbitrary sets of objects. Just remember that any object that might get passed <q>over the wire</q> must inherit from <code class="API" base="twisted.spread.pb">Referenceable</code> (or one of the other flavors). If you try to pass a non-Referenceable object (say, by returning one from a <code>remote_*</code> method), you'll get an <code class="API" base="twisted.spread.jelly">InsecureJelly</code> exception<span class="footnote">This can be overridden, by subclassing one of the Serializable flavors and defining custom serialization code for your class. See <a href="pb-copyable.xhtml">Passing Complex Types</a> for details.</span>.

558.

References can come back to you

559.

If your server gives a reference to a client, and then that client gives the reference back to the server, the server will wind up with the same object it gave out originally. The serialization layer watches for returning reference identifiers and turns them into actual objects. You need to stay aware of where the object lives: if it is on your side, you do actual method calls. If it is on the other side, you do <code>.callRemote()</code><span class="footnote">The binary nature of this local vs. remote scheme works because you cannot give RemoteReferences to a third party. If you could, then your object A could go to B, B could give it to C, C might give it back to you, and you would be hard pressed to tell if the object lived in C's memory space, in B's, or if it was really your own object, tarnished and sullied after being handed down like a really ugly picture that your great aunt owned and which nobody wants but which nobody can bear to throw out. Ok, not really like that, but you get the idea.</span>.