[Twisted-Python] Both pb.Copyable and pb.RemoteCopy: How to use?
Hi all! 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. 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. :-) ) Thanks! Steve Freitas
Steve Freitas <sflist@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
Hi David! 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! Thanks again! Steve On Thursday 10 February 2005 09:23 am, David Bolen wrote:
Steve Freitas <sflist@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
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
participants (2)
-
David Bolen -
Steve Freitas