2012/6/22 Jens Geyer <[email protected]>: > THRIFT-1037 I read the ticket and took a glance at the patch, but unfortunately I'm still not familiar enough with thrift to understand if this matches my ideas.
Anyway, I implemented a small sample project that pretty much does what I want. I left the latest version at work and am now on my way into holidays, so I'll have to share it in about 3 weeks. For now you can have the a bit older version. The idea I implemented is straight forward and splits up all operations into the actions "DoXXX" and "HandleXXX" for both client and server. Those methods are implemented such that "DoXXX" on the client invokes "HandleXXX" on the server and "DoXXX" invokes "HandleXXX" on all connected clients. Typically "HandleXXX" on the server modifies the server state (if it was stateful) and eventually dispatch the event (or others) to all clients by invoking "DoXXX". This works because both "DoXXX" and "HandleXXX" do not have return values. The messages exchanged on the bidi-pipe basically just include the name of the method (i.e. "XXX") and a set of parameters that need to be passed into "[Do|Handle]XXX" which again is really convenient. Of course the biggest drawback of this technique is, that all operations are asynch and retrieving values must happen in two steps. In theory even that should be possible if the server does not immediately push messages such that it does not deadlock itself with sending the "HandleXXX" feedback and fresh new "DoXXX" events. Implementing something useful there is far from trivial. Feel free to use the ideas for your work. If the plane does not crash I'll be back from the caribics in 3 weeks. I'm looking forward to read you again! Cheers -- Dominik Psenner ## OpenPGP Key Signature ################################# # Key ID: B469318C # # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # ##########################################################
Remoting Sandbox_9.tar.gz
Description: GNU Zip compressed data
