[IPython-dev] Qt/Curses interfaces future: results of the weekend mini-sprint (or having fun with 0mq)
Thu Mar 25 11:14:06 CDT 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
> I'll try to work a bit on this again tomorrow.
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
More information about the IPython-dev