Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I personally find them roughly equivalent, but RPyC's author (<a href="http://rpyc.wikispaces.com/about" rel="noreferrer">here</a>) 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...:</p> <blockquote> <p>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?</p> </blockquote> <p>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).</p> <p>A more independent voice, David Mertz, offers <a href="http://www.ibm.com/developerworks/linux/library/l-rpyc/" rel="noreferrer">here</a> 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.</p> <p>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. <a href="http://json-rpc.org/" rel="noreferrer">JSON-RPC</a> via <a href="http://json-rpc.org/wiki/python-json-rpc" rel="noreferrer">this</a> module, or the like...!-).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload