Bi-directional RPC options for cross-language client/server

I'm trying to lay out an idea for a project, where a client-side GUI can be developed in python, and the GUI can be driven by a backend in potentially any other language, over RPC.
More specifically, right now I am working with PyQt on the client side, and Go as the initial backend.

Here are my goals:

• PyQt client
• Roles: View, Controller
• Oneway calls (SIGNAL/SLOT), such as: button.clicked -> RPC.handleSignal
• Request/Reply RPC, such as: rowCount = model.rowCount -> RPC.call.model.rowCount
• Agnostic backend (Go in this case)
• Roles: Controller, Model
• Oneway calls (Emit SIGNAL), such as: model.dataChanged -> RPC.emitSignal

I refer to each of these as having controller roles becase a user could define signal/slot connections in the GUI client side, or the backend could define its own signal/slot connections over RPC, assuming knowledge about the view on the client side. It would depend solely on how the user wants to set up the controller.

I am looking at Thrift right now, vs say a lighter weight basic rpc without an IDL. But mainly my question is whether it would be a messy approach to try and do Thrift as two .thrift files, with client/server <----> client/server (two connections), in order to get the bi-directional functionality? The benefit I see with Thrift is the IDL, so that I can build my interface specifically, and backend code can just implement the parts they want.

Does anyone have a recommendation for a solution to this? Two Thrift interfaces? One Thrift interface, that provides a service to let the client establish a second simple socket to receive oneway calls from the server? Or is Thrift somewhat even overkill here? While the backend -> GUI interface is really only a single service function, the GUI -> backend could expand a bit (modelHandlers, slotHandlers, general server status queries).

(Edit) More Thoughts

Part of me is thinking that the pattern could be done with any RPC framework, and it would be like this?

1. Backend server process starts; listens on port
2. Client GUI starts; connects to server RPC; listens on new port; sends port to server via RPC call
3. Server receives port from client, and binds to it for a second RPC connection
4. Client and Server have 2 connections, for bi-directional RPC

On the network when you connect to a server via TCP (or any other similar connection based protocol), when connecting your PC already chooses and listens on a (pseudo/relatively) random port in order to receive the servers answers. So for that matter, as long as the server keeps the connection and both sides keep the connection alive you already have a bi-directional connection. So from a technical, low-level point of view you do not need to initiate a second connection.

Depending on your RPC system it may or may not use TCP and it may or may not feature bi-directional communication (or rather, bi-directional communication initialization).

Now, for thrift, there does not seem to be much documentation there yet (no API reference). But checking the example code it seems to abstract the connection-handling away and use request/response communication only. So in this case, yes, you would have to listen on a defined port client side and tell the server, so the server can initiate a request/response communication.

Go itself provides the rpc package, which is exclusive to go data, so will not help you.

However, it also provides the websocket package. Although initially targeted at webserver to webbrowser communications it is a bi-directional protocol (that’s what it’s about after all) and can be used by any application type. It may not be as efficient size-/bandwidth-wise but it does the job.

I’m not sure about the state of implementation in the go package. The Conn type does have an origin field but the Conn.Dial function example passes http://localhost; I’m not sure whether this is replaced with a remotely-accessible websocket origin. The Handler.ServeHTTP function provides an http.ResponseWriter, which you can probably use to initiate connection as well. At least that’s the first thing I would test.

An alternative, if you are comfortable with using a defined dataformat and handle networking yourself, is protobuf. There is a community project for go bindings to protobuf. You could then handle the TCP connection yourself (connecting to it and sending your data, receiving the data, holding the connection info etc).

As for other alternatives, you may want to check the community packages page and or the community projects page (especially the Go Ajax and go-xmlrpc – both are very rudimentary at this point though).