[IPython-dev] Qt/Curses interfaces future: results of the weekend mini-sprint (or having fun with 0mq)

Brian Granger ellisonbg at gmail.com
Thu Mar 25 12:14:06 EDT 2010


> With good use of the status socket the above shouldn't happen, as
> control requests shouldn't be posted by clients if the kernel is busy,
> I think.  But in general, I do agree that we'll probably better off
> with a single channel for execution and one for publication, the
> proliferation of sockets isn't a good thing.  I think the status and
> control 'channels' (not sockets) are needed though, we just need to
> have a nice api to manage the messaging on these channels that makes
> it not too confusing in practice.  I'm pretty sure it's quite doable,
> from the experience so far.


>> I know this is something you really want to have.  But I don't think
>> it is possible, even for the synchronous line based frontend.  This is
>> because all frontends will need to have an event loop and the event
>> loop itself needs handle the 0MQ messaging stuff.  But I am willing to
>> explore this idea further to see if it is possible.  I think the next
>> step is to implement a real event loop in pyzmq and then use in for
>> our current frontend/kernel prototype.  That will better show us what
>> the abstractions and interfaces are.
> Let's finish up the messaging until we're happy and we'll see if this
> is doable or not in practice.  I trust your intuition and you may be
> right, though we should still strive to centralize as much as possible
> in one common api that all frontends can reuse, to minimize code
> duplication.
> I'll try to work a bit on this again tomorrow.

Sounds great.



Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

More information about the IPython-dev mailing list