[IPython-dev] Sockets by name, adding a control socket...

[Brian Granger]

On Wed, Nov 3, 2010 at 9:58 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> [ sorry for not having replied to a few mails on the list and starting
> a new thread, I'm trying to avoid bottlenecking Min right now.  I'll
> catch up with the list asap]
>
> Min and I today had a long discussion about the messaging spec and our
> sockets, with an eye towards harmonizing as much as possible the
> design of the kernels in the parallel code with that of the
> interactive one (as those guys will get merged hopefully soon).
>
> As usual, this is all based on our reference doc:
> http://ipython.scipy.org/doc/nightly/html/development/messaging.html
>
> There are two main points:
>
> 1. Our 'XREP' socket does too much, and it would be cleaner if we
> break it into two.  Right now that socket manages both control
> commands (liek connect or shutdown) and things related to user
> 'shell-like' activity (code execution, object info, history, etc).  In
> the parallel code Min uses a separate control socket, and it seems
> clear we should do the same here.  So the plan would be to have two
> sockets (we'll get to the names later):
>
> XREP-a: used for
> - code execution
> - object info
> - completion
> - history
> - anything else that could come up in the future that's along these
> lines (i.e. mostly user namespace-related manipulations)
>
> XREP-b: used for:
> - connect
> - shutdown
> - abort
> - kernel attribute access
> - other kernel-specific manipulations

The connect/shutdown/abort logic does seem to to together, but kernel
attribute access seems to go with the XREP-a things.  For the parallel
stuff, the different between these two types of XREP channels makes
sense, because they are talking to different processes.  But here, it
is just 1 process, so I am not sure it makes sense.  I am a little
concerned about un-needed proliferation of channels.

>
> 2. We should name all of our sockets based on what they do, not on the
> zmq socket type they use.  Min and I scribbled a bunch on paper and
> came up with:
>
> - XREP-a: 'shell'.   It handles all the things that are 'shell-like'.
> - XREP-b: 'control'. It handles all kernel control stuff.
> - PUB: 'iopub'.  This publishes the i/o streams.
> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
> when needed.
> - 'heartbeat': can stay, it's already named by function and not by type

Yep, we definitely need better names.  Some comments:

> - XREP-a: 'shell'.   It handles all the things that are 'shell-like'.
> - XREP-b: 'control'. It handles all kernel control stuff.

Both of these are pretty good if we separate the XREP channel into 2.

> - PUB: 'iopub'.  This publishes the i/o streams.

But we publish more than the io streams on this channel.  In reality,
it is for sideeffects, so would that name make sense.

> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin

I think he "k" is a bit too short and confusing.  Maybe kernelstdin?
Or just stdin?



> Variations, suggestions, etc, all welcome.
>
> We think Min will start updating the parallel code to follow this
> convention, minor tweaks can always be made later but I doubt we'll
> want to make major changes.  But feedback on the names is welcome, if
> anyone has any.

Great, glad you were able to talk about this.

Cheers,

Brian

> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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