[Twisted-Python] Re: Both pb.Copyable and pb.RemoteCopy: How to use?
sflist at ihonk.com
Wed Feb 16 20:41:00 EST 2005
Thanks again for your, as ever, wonderfully detailed response. I've gotten
symmetric function calling working thanks to your information. Now it's time
to leap into the authentication side, with perspectives, viewpoints and
minds, oh my!
On Thursday 10 February 2005 09:23 am, David Bolen wrote:
> 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
> 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
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python