Browsing Chinese (Simplified) translation

540.

which causes the server's <code>.remote_echo()</code> method to be invoked. (running <code>.callRemote("boom")</code> would cause <code>.remote_boom()</code> to be run, etc). Again because of the delay involved, <code>callRemote()</code> returns a <code class="API" base="twisted.internet.defer">Deferred</code>. Assuming the remote method was run without causing an exception (including an attempt to invoke an unknown method), the callback attached to that <code class="API" base="twisted.internet.defer">Deferred</code> will be invoked with any objects that were returned by the remote method call.

541.

In this example, the server's <code>Echoer</code> object has a method invoked, <em>exactly</em> as if some code on the server side had done:

542.

echoer_object.remote_echo("hello network")

543.

and from the definition of <code>remote_echo()</code> we see that this just returns the same string it was given: <q>hello network</q>.

544.

From the client's point of view, the remote call gets another <code class="API" base="twisted.internet.defer">Deferred</code> object instead of that string. <code>callRemote()</code> <em>always</em> returns a <code class="API" base="twisted.internet.defer">Deferred</code>. This is why PB is described as a system for <q>translucent</q> remote method calls instead of <q>transparent</q> ones: you cannot pretend that the remote object is really local. Trying to do so (as some other RPC mechanisms do, coughCORBAcough) breaks down when faced with the asynchronous nature of the network. Using Deferreds turns out to be a very clean way to deal with the whole thing.

545.

The remote reference object (the one given to <code>getRootObject()</code>'s success callback) is an instance the <code class="API" base="twisted.spread.pb">RemoteReference</code> class. This means you can use it to invoke methods on the remote object that it refers to. Only instances of <code class="API" base="twisted.spread.pb">RemoteReference</code> are eligible for <code>.callRemote()</code>. The <code class="API" base="twisted.spread.pb">RemoteReference</code> object is the one that lives on the remote side (the client, in this case), not the local side (where the actual object is defined).

546.

In our example, the local object is that <code>Echoer()</code> instance, which inherits from <code class="API" base="twisted.spread">pb.Root</code>, which inherits from <code class="API" base="twisted.spread">pb.Referenceable</code>. It is that <code>Referenceable</code> class that makes the object eligible to be available for remote method calls<span class="footnote">There are a few other classes that can bestow this ability, but pb.Referenceable is the easiest to understand; see 'flavors' below for details on the others.</span>. If you have an object that is Referenceable, then any client that manages to get a reference to it can invoke any <code>remote_*</code> methods they please.

547.

The <em>only</em> thing they can do is invoke those methods. In particular, they cannot access attributes. From a security point of view, you control what they can do by limiting what the <code>remote_*</code> methods can do.

548.

Also note: the other classes like <code class="API" base="twisted.spread.pb">Referenceable</code> allow access to other methods, in particular <code>perspective_*</code> and <code>view_*</code> may be accessed. Don't write local-only methods with these names, because then remote callers will be able to do more than you intended.

549.

Also also note: the other classes like <code class="API" base="twisted.spread">pb.Copyable</code> <em>do</em> allow access to attributes, but you control which ones they can see.