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

[Brian Granger]

Boy I am busy these days...continuing on...

On Wed, Nov 3, 2010 at 10:28 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> 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.
>
>
But wouldn't both XREP channels probe the users namespace?


> 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.
>
>
Yes, that does make sense.  But then I think that the control channel should
*never* touch the user's namespace.


> 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.
>
>
I am not too sure of this.  If you think about remote connections, this is 1
more firewall port that has to be opened.  Also 1 more point of security...


> >> - 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)...
>
>
I just think that IO is too limiting because of our moving the payload to
this channel.  So maybe:

datapub?


> 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.
>
>
Yes, I think that kernel_stdin is better.

Cheers,

Brian


> Thanks for the feedback!
>
> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/50d39948/attachment.html>