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

[Brian Granger]

Fernando,

> 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.

Agreed.


>> 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.

Cheers,

Brian


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