>>>>> "Ted" == Ted Dunning <[email protected]> writes:
Ted> That is, could there actually be a fully operational Thrift transport Ted> that moves requests both ways on a single socket? You would give it Ted> something that implements the server interface and it would give you Ted> back something that also implements the interface. You could call it Ted> and it could call you in horrifically complicated but very cool ways. Right. I had the same thought, in this form: You could take a normal Thrift service spec and essentially produce two services from it. A server method that returned an X would become an async server method, and a (client-side) server method that took an X as an argument would be generated to run on the client to receive the method result as originally intended. You would need something under the covers to keep track of the outstanding calls and match them up with their incoming async results (if any). It would begin to look something like the Twisted/Thrift solution, which conceptually already does this (with the help of Twisted's deferreds and a client-side dictionary of outstanding requests). The two are NOT exactly the same, just quite similar. As Doug said originally: >> you'd have make sure you don't "miss" sending a client a message if they >> finished their Async call but haven't reestablished a new one. But, to show a bit more similarity, Joel pointed out that his suggestion allows the client to immediately know when the server has gone away. You can do this already with the Twisted/Thrift combination: the client makes a Thrift method call, say adviseOnShutdown, and immediately gets back a deferred. That pending call just sits there client-side (the caller and the Twisted/Thrift code both have a reference to the Deferred) until the server either actively returns to indicate that it's going away, or disappears, in which case the client gets the disconnect as a failure from the pending deferred. I hope the above all makes some sense! Terry
