Question

I am looking for a remote procedure call engine for Python and I’ve found that PyRo (Python Remote Object) and RPyC (Remote Python Call) are both the kind of thing I am searching for.

However, I am curious to know how they compare to each other and what are their pros and cons ?

Answer 1

I personally find them roughly equivalent, but RPyC’s author (here) claims more simplicity (and maybe for somebody not all that used to distributed computing he’s got a point; I may be too used to it to make a good judge;-). Quoting him…:

although PYRO has a long list of
considerable projects in its resumè, I
find setting up a server too
complicated, if you take into account
the amount of code needed, registering
objects, running name servers, etc.
Not to mention the number of different
concepts you have to consider (events,
rebinding, with or without name
servers, proxy vs. attribute-proxy,
names have to be unique, etc.). And
it’s limited (remote objects must be
picklable so you can’t work with
remote files, etc.). All in all, PYRO
has too many special cases and is
generally too complicated (yes, I
consider this complicated). So of
course I’m not an independent reviewer
— but judge for yourself. Isn’t RPyC simpler and cleaner?

On the other side of the coin, PyRO does try to provide some security (which RPyC’s author claim is too weak anyway, and underlies many of PyRO’s claimed complications).

A more independent voice, David Mertz, offers here a good explanation of RPyC (PyRO has been around much longer and David points to previous articles covering it). The “classic mode” is the totally generally and simple and zero-security part, “essentially identical to Pyro (without Pyro’s optional security framework)”; the “services mode” is more secure (everything not explicitly permitted is by default forbidden) and, David says, ” the service mode is essentially RPC (for example, XML_RPC), modulo some details on calling conventions and implementation”. Seems a fair assessment to me.

BTW, I’m not particularly fond of single-language RPC systems — even if Python covers 99% of my needs (and it’s not quite THAT high;-), I love the fact that I can use any language for the remaining 1%… I don’t want to give that up at the RPC layer!-) I’d rather do e.g. JSON-RPC via this module, or the like…!-).