<div class="gmail_quote">On Tue, Mar 23, 2010 at 5:01 PM, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The basic issue we need to solve is the ability to have out-of-process<br>
interfaces that are efficient, simple to develop,  and that support<br>
fully asynchronous operation.  In today&#39;s ipython, you type code into<br>
a program that is the same tasked with executing the code,  so that if<br>
your code crashes, it takes the interface down with it.  So we need to<br>
have a two-process system where the user-facing client and the kernel<br>
that executes code live in separate processes (we&#39;ll retain a minimal<br>
in-process interface for embedding,  no worries, but the bulk of the<br>
real-world use should be in two processes).<br>
<br>
We want the user-facing client (be it readline-, curses- or qt-based)<br>
to remain responsive when the kernel is executing code, and to survive<br>
a full kernel crash.  So client/kernel need to communicate, and the<br>
communication should hopefully be possible *even when the kernel is<br>
busy*, at least to the extent that low-level messaging should continue<br>
to function even if the kernel is busy with Python  code.<br>
<br>
Up until now our engines use Twisted, and the above requirements can<br>
simply not be met with Twisted (not to mention Twisted&#39;s complexity<br>
and the concern we have with it not being ported soon to py3).  We<br>
recently stumbled on the 0mq messaging library:<br>
<br>
<a href="http://www.zeromq.org/" target="_blank">http://www.zeromq.org/</a><br>
<br>
and Brian was able to quickly build a set of Python bindings for it<br>
(see  link at the 0mq site, I&#39;m writing this offline) using Cython.<br>
They are fast, we have  full  control over them, and since Cython is<br>
python-3 compliant, it means we can get a py3 version anytime we need.<br>
<br>
0mq is a really amazing library: I&#39;d only read about it recently and<br>
only used it for the first time this weekend (I started installing it<br>
at Brian&#39;s two days ago), and I was blown away by it.  It does all the<br>
messaging in C++ system threads that are 100% Python-threads safe, so<br>
the library is capable of queuing messages until the Python layer is<br>
available to handle them.  The api is dead-simple, it&#39;s blazingly<br>
fast, and we were able to get in two intense days a very real<br>
prototype that solves a number of problems that we were never able to<br>
make a dent into with Twisted.  Furthermore, with Twisted it was only<br>
really Brian and Min who ever wrote major amounts of code  for<br>
Ipython: twisted is really hard to grasp and has layers upon layers of<br>
abstraction,  making it a very difficult library to  pick up without a<br>
major commitment.  0mq is exactly the opposite: Brian explained the<br>
basic concepts to me in a few minutes (I haven&#39;t read a single doc<br>
yet!), we did some queuing tests interactively (by just making objects<br>
at an ipython prompt) and we then started writing a real prototype<br>
that now works.  We are very much considering abandoning twisted as we<br>
move forward and using 0mq for everything, including the distributed<br>
computing support (while keeping the user-facing apis unchanged).<br>
<br clear="all"></blockquote></div>IMHO it is a great idea to separate the main IPython engine from the frontend.<br>But while implementing an RPC framework over 0mq from ground up should <br>not be a very difficult task and will definitely bring you a lot of fun, have you <br>
considered something preexisting like RPyC (<a href="http://rpyc.wikidot.com/">http://rpyc.wikidot.com/</a>) for <br>example. The reason is that IPython already has a lot of useful and exciting<br>functionality and yet another RPC framework is somewhat too much. Plus,<br>
you don&#39;t have to think about these too low level details like communication <br>protocols, serialization etc.<br><br>Regards,<br>-- <br>Mikhail Terekhov<br>