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

[Fernando Perez]

On Tue, Mar 23, 2010 at 2:01 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> This is the summary of those
> results.  I hope this thread can serve as a design brief we'll later
> formalize in the docs and which can be used to plan for a possible
> GSOC submission, for example (which the Qt guys have in mind).

Sorry for the brevity, I have a crazy day today and can't work on this
but want to jot down some design thoughts from last nights
tab-completion exercise before I forget so they're here for further
discussion.

- We probably want a second REQ/XREP socket used strictly for control
messages.  This will  make it easier to handle them separate from code
execution.

- The kernel should also  have  a second PUB socket where it simply
posts busy/ready status updates.  This can then be used by clients to
check before making certain control requests like tab completion that
should be avoided when busy (I know, there's a race condition if it's
implemented naively, but I think it can be avoided simply by assuming
that control requests are made only when the status socket is in
'ready' status, but that clients can't assume they will get them
honored, they have to  check the result and be ready to time out if
needed).

- We're starting to see the architecture needed for qt/wx/curses
applications now: we should break what we now call the 'frontend' into
2 objects:

1. 'Client': object that talks to kernel with zmq messages, does NOT
talk directly to user and doesn't know if it's in qt, wx, curses or
terminal.

2. 'Frontend': object that talks to user, has UI dependencies (qt,
readline, etc) but does NOT have zmq dependencies.  It *only* talks to
client object via python calls,  it does not do messaging.

Even the code in frontend.py today is starting to have a bit of this,
now we just have to make the split, and that will quickly indicate
where the design divisions need to go.


Gotta go,

f