Preparing an existing RPC mechanism for the standard library
Hello, I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired. I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this. Thanks, -- -- Guilherme H. Polo Goncalves
On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo <ggpolo@gmail.com> wrote:
Hello,
I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired.
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
I know from my end I am not even familiar with rpyc so I have no comment. And I suspect most other people have a similar reason for having not commented on this so far. -Brett
On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon <brett@python.org> wrote:
On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo <ggpolo@gmail.com> wrote:
Hello,
I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired.
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
I know from my end I am not even familiar with rpyc so I have no comment. And I suspect most other people have a similar reason for having not commented on this so far.
I believe the reason that the OP is considering RPyC is because it is the most Pythonic RPC mechanism of the lot. That, and its relative simplicity, are the reasons I recently chose RPyC for a project, and it worked out pretty well. If any RPC mechanism is added to the standard library, I hope it has an API as Pythonic as RPyC's! I ran into two main problems while using RPyC (v2.60), neither of them show breakers for me. The first was that debugging it can be hard because its exception handling (propagation across the RPC link) isn't good enough (yet). The second is that the RPC is two-way and very transparent, so that once the application became complex I had to take special measures to avoid deadlocks. All things considered, RPyC got the job done. I know RPyC's developer and maintainer, Tomer Filiba, and he's a great guy, though recently much busier than he used to be. He had plans to add distributed computing capabilities to RPyC in version 3.0, and probably quite a few other features, but AFAIK development is currently frozen. I'm CC-ing the RPyC newsgroup in hopes that he (and the users) will comment on this. - Tal
2008/3/24, Tal Einat <taleinat@gmail.com>:
On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon <brett@python.org> wrote:
On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo <ggpolo@gmail.com> wrote:
Hello,
I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired.
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
I know from my end I am not even familiar with rpyc so I have no comment. And I suspect most other people have a similar reason for having not commented on this so far.
I believe the reason that the OP is considering RPyC is because it is the most Pythonic RPC mechanism of the lot. That, and its relative simplicity, are the reasons I recently chose RPyC for a project, and it worked out pretty well. If any RPC mechanism is added to the standard library, I hope it has an API as Pythonic as RPyC's!
I ran into two main problems while using RPyC (v2.60), neither of them show breakers for me. The first was that debugging it can be hard because its exception handling (propagation across the RPC link) isn't good enough (yet). The second is that the RPC is two-way and very transparent, so that once the application became complex I had to take special measures to avoid deadlocks. All things considered, RPyC got the job done.
I know RPyC's developer and maintainer, Tomer Filiba, and he's a great guy, though recently much busier than he used to be. He had plans to add distributed computing capabilities to RPyC in version 3.0, and probably quite a few other features, but AFAIK development is currently frozen. I'm CC-ing the RPyC newsgroup in hopes that he (and the users) will comment on this.
I've talked with him before posting this here Tal. Also, the development of the new version is active.
- Tal
-- -- Guilherme H. Polo Goncalves
hi all. i don't feel i may join in this discussion as i'm certainly biased, but i don't want to just leave it on the wall. for those of you who haven't heard of rpyc, here's a link: http://rpyc.wikispaces.com/ and a short demo/tutorial at http://rpyc.wikispaces.com/tutorial i can bring many use cases that demonstrate rpyc's superiority over other RPC mechanism, but then again, rpyc has its drawbacks too (mainly security and frequent IOs). i can make a list of both pros and cons, but i don't see how it could advance this discussion. just some final words, as guilherme has said, i am now actively working on rpyc3.0. in fact the core (parallel to rpyc2.6) is already stable and quite tested (you can find it on the svn), but if any attempt is made to integrate rpyc into the stdlib, it should wait until the final 3.0 release. -tomer On Mar 24, 12:31 pm, "Guilherme Polo" <ggp...@gmail.com> wrote:
2008/3/24, Tal Einat <talei...@gmail.com>:
On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon <br...@python.org> wrote:
On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo <ggp...@gmail.com> wrote:
Hello,
I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired.
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
I know from my end I am not even familiar with rpyc so I have no comment. And I suspect most other people have a similar reason for having not commented on this so far.
I believe the reason that the OP is considering RPyC is because it is the most Pythonic RPC mechanism of the lot. That, and its relative simplicity, are the reasons I recently chose RPyC for a project, and it worked out pretty well. If any RPC mechanism is added to the standard library, I hope it has an API as Pythonic as RPyC's!
I ran into two main problems while using RPyC (v2.60), neither of them show breakers for me. The first was that debugging it can be hard because its exception handling (propagation across the RPC link) isn't good enough (yet). The second is that the RPC is two-way and very transparent, so that once the application became complex I had to take special measures to avoid deadlocks. All things considered, RPyC got the job done.
I know RPyC's developer and maintainer, Tomer Filiba, and he's a great guy, though recently much busier than he used to be. He had plans to add distributed computing capabilities to RPyC in version 3.0, and probably quite a few other features, but AFAIK development is currently frozen. I'm CC-ing the RPyC newsgroup in hopes that he (and the users) will comment on this.
I've talked with him before posting this here Tal. Also, the development of the new version is active.
- Tal
-- -- Guilherme H. Polo Goncalves _______________________________________________ Python-ideas mailing list Python-id...@python.orghttp://mail.python.org/mailman/listinfo/python-ideas
On 20/03/2008, at 12:45, Guilherme Polo wrote:
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
I think the route you would have to go is making a pep, and one of the things I would like to see in this pep would be why rpyc and not any of the other rpc modules around (like the not recomended for general use zrpc or pyro or the thing the guys from twisted have). Only if your pep is accept I think you should waste your time making it better for the stdlib. The two "think" in my last paragraph are there because I am not sure this the right route, this is just a guess. -- Leonardo Santagada
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
Might think about reviving the ILU kernel (just the runtime, not the stubbers) as a Python-only module. Open source, pretty complete bindings to Python, multithreaded, threadsafe, etc., etc. On the other hand, I haven't even compiled it in 6 years :-). The key advantage would be that ILU speaks a number of different RPC protocols under the covers, and it's straightforward to add new ones. I'd love to see our implementation of wmux (a way of multiplexing multiple virtual connections, in either direction, over a single TCP connection) actually in use. http://www2.parc.com/istl/projects/ILU/ Bill
participants (6)
-
Bill Janssen -
Brett Cannon -
Guilherme Polo -
Leonardo Santagada -
Tal Einat -
tomer filiba