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

[Fernando Perez]

On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> 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.

Our reasoning for putting attribute access there was to keep the -a
socket strictly for things the user would normally see in his regular
namespace, and -b for things that had to do with manipulating the
kernel object itself.  While it's true that one can get the kernel via
'ip = get_ipython()' and start working on it, that's not the "regular"
mode of operation in most user activities.

And Min brought up a compelling point for wanting the separate kernel
control channel: so that things like abort commands can jump to the
front of the queue.  This will become more important once the web
notebook makes it natural to queue up multiple cells for execution,
for example.

And once we update the connection logic to use the mechanism Min has
with a single socket for initial connection and all others
auto-negotiated after that, having one more socket shouldn't be too
big of a deal.  I do agree with you that we don't want these things
growing like dandelions, but I don't think we have too many more in
store, to me this seems like a reasonably complete coverage of what we
need.

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

We thought about that but it seemed a little too long... And we looked
at the actual list of what goes there, right now we have:

# Streams (stdout, stderr, etc)
# Python inputs
# Python outputs
# Python errors
# Kernel status
# Kernel crashes

It seemed like most of this was the kind of thing that normally shows
up on i/o streams at a console/log, so while not literally being
stdout/err, 'iopub' seemed like a reasonable, and short, way to
describe 'publish all i/o activity produced by the kernel'.  I/O is
more or less by definition a side effect (which is why functional
languages typically have to do something a bit odd to provide it, as
it doesn't really fit into a purely functional paradigm)...

But if this justification doesn't convince you, I'm happy to
reconsider (though I'd like to find something a little shorter than
side_effects, we're likely to use these names a lot everywhere...).

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

Yes, the k alone didn't seem very nice.  kernel_stdin?  (In general, I
think we should avoid run-in words without underscores as much as
possible).  It's a bit long but this one isn't likely to be used
super-often, and I think it's a good idea to keep explicit the fact
that this one is a special socket handling something from the kernel,
rather than client-side stdin.

Thanks for the feedback!

Cheers,

f