problem with selecting remote procedure calls

eric johansson esj at
Thu Jul 23 05:10:17 CEST 2015

 while this is related to my speech recognition through the next project, is actually a good question for RPCs in general. Specifically, are there any good-RPCs out there that are fast, supported, and easy to use?

The Google Doc image given above shows the kind of things I'm doing to make speech recognition, running on windows, drive linux. The relay and emitter pair are almost trivially easy. The RPC is used to communicate the Windows scan code or codes for a given key and then the inner side translates that scan code into an actual code understood by Linux and it is shoved into the input queue.

 it's much harder to create a natlink module  with a matching object in the RPC server. In this case, the  class "data jammer" queries the application I built and extracts data necessary to inform the grammar back in the natlink module. Once the grammar executes, "data jammer" is called again to transform the results of the recognized grammar into usable data that  will drive another application. In this case, I stuffed the data into the Windows input queue which in turn gets injected into win_relay.

At this point, this is where I'm having some trouble with the RPC choices. I initially settled on rpyc  because it was easy, it looked like it would do what I needed and  it might even be fast enough. The problem being that the user community is mostly inhabited by crickets. Second problem is that it's not clear if I can export multiple objects from a single server. Ideally, I want there to be  a pair of Python programs executing for any given grammar. The first would be the module imported into natlink  and the other would be it's matching partner in crime on the linux side.

 I'm looking for ways to implement a plug-in architecture with independent objects.  I would welcome advice on pieces I can recycle to meet my needs.  for example, which Python RPC environment would best suit my needs. Remember, it needs to be relatively light because execution time does have an  influence on recognition accuracy and speed.

 thanks in advance
 --- eric

More information about the Python-list mailing list