yes, well, i haven't heard of execnet either, but it looks more like a
competitor of the new multiprocessing module.
on the PR front, it's better to compare how simple rpyc is, versus the
alternatives:
* pyro - complicated setup (requires name servers, etc.)
* xmlrpc - very limited scope
* soap / wsdl - overly complicated, slow, bloated
* multiprocessing - limited scope (doesn't have proxies, etc.)
* execnet - from what i read, it seems to aim at remote code execution. rpyc
doesn't aim there.
if you want remote code execution with rpyc, just do
c = rpyc.classic.connect(...)
c.execute("code to run remotely")
anyway, it's not the speed that seems the edge here. rpyc is quite efficient
and uses a compact binary protocol -- but the main benefits are:
* ease of use
* minimal setup: import rpyc; c = rpyc.connect(...);
c.root.do_something(...)
* transparency - can work with existing code that expects "real" objects
* symmetry - both client and server can process requests, allows for
callbacks, async execution, etc.
-tomer
An NCO and a Gentleman
On Fri, Mar 4, 2011 at 14:59, Fruch <[email protected]> wrote:
> First time I've heard about Execnet, and I think it's not match
> to simplistic api of the classic SlaveService
> the whole "Share-Nothing" and confusion channels send/receive, to much for
> me to warp my head with.
>
> I think we could beat them in PR.. :)
> Now I need a way to compare between them (speed wise)
>
> even the RPyC tutorial looks better then their documentation.
>
> On Friday, March 4, 2011 1:39:01 PM UTC+2, Alex Grönholm wrote:
>>
>> 04.03.2011 08:02, Fruch kirjoitti:
>>
>> Hi all,
>>
>> I'm starting what I've committed to.
>> I have a way of first, keep bugs that already happened out of the
>> system, and then look for the new one.
>>
>> 1.
>> I have a small request from people who report issues, or submit bug.
>> If you could write a test for a problem you see, so could add it to our
>> testing pool.
>> (and also use it when a fix is needed)
>>
>> *Tomer*, can you add a tag in the github, for marking issues that needed
>> to have a test for ?
>> that way I could go over then and try to write a test for them.
>>
>> 2.
>> I want to measure the performance of rpyc,
>> (this is the first degree of PR, showing nice graph to prove it's working
>> faster then other solutions :) )
>> and I need some idea on how to measure, and what are the "rivals" we want
>> to compare with .
>>
>> Execnet is probably the closest competitor. It has support for Python 3.x,
>> Jython and PyPy, which RPyC currently lacks (at least for the first two).
>> RPyC has the advantage of a more liberal license (ExecNet is GPL), making it
>> more viable for use in commercial applications.
>>
>>
>> Fruch
>>
>>
>>
