[Twisted-Python] Re: Both pb.Copyable and pb.RemoteCopy: How to use?

[David Bolen]

Steve Freitas <sflist at ihonk.com> writes:

> I'm plugging through the pb docs, and a note says that if you want
> to send an object over the wire in either direction, just make the
> desired class inherit from both pb.Copyable and
> pb.RemoteCopy. That's cool. But, what to do after that? Meaning,
> only the sender can grab a root object (pb.Root), and so only the
> sender can send jellyable objects out.

Not quite - jellyable objects may be used in any portion of the PB RPC
mechanism, originating on either side of the connection.

> I realize one answer to this would be to run a server on both sides,
> but I'm in the situation where my client can contact my server, but
> not the other way around. So, is it possible for the sender to
> contact the receiver, and then for them to start swapping objects
> willy nilly? (Note that the next place I'm going to take this is
> pb.Cacheable, so beware. :-) )

Yes.  E.g., after the client connects, it may receive objects as part
of responses to queries, and those objects may be any flavor of
jellyable (copyable, cacheable, referenceable, etc...).  In turn, the
client can then use those objects as parameters for further calls to
the server.  In the case of copyable for example, this results in
another remote copy, in the case of referenceable the object reference
is sent and on the server side it actually receives a reference to the
original instance of the object that it first sent back to the client.
(Note that referenceables are only usable in this way within a single
session)

If the client sends over a referencable for something that it
originates, then the server may use that object to initiate
unsolicited calls back to the client, even though the client may have
formed the connection to the server in the first place.  That's why
the PB docs talk about a PB session really being peer-to-peer once
established as either side can initiate a request.

So you could, for example, have the client call a well-defined method
on the server root object (or any other server referenceable) to pass
on a useful reference that the server could then use for later calls.

The "mind" object in an authenticated PB session can also be useful as
it can provide access to a reference to the client that is
automatically provided on each call through that session.

One of the things I try to tell developers here is that while PB is
very capable and can appear daunting, it might help to realize how
simple (in the elegant sense) it is.  There's not really as much
"magic" going on as you might think, and once a session has been
established, everything is pretty symmetric in terms of what can be
done across that session.

-- David