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

[MinRK]

On Tue, Nov 16, 2010 at 14:46, Brian Granger <ellisonbg at gmail.com> wrote:

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

No. Control does: connect, shutdown/kill/signal, abort, and access *kernel*
properties, never touching the user 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.
>

I don't think we have proposed that it does, but you are right, it
shouldn't.


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

I'm fine with something other than iopub, but I still think it's the most
descriptive.  What goes in the payload that is not IO?  Plots absolutely are
IO. Maybe not stdio, but IO nonetheless.

I'm not entirely sure that just 'pub' is inappropriate here, since it's the
general purpose publish socket.  So far, all of what it publishes is IO, as
far as I know, but there could be future side effects that might not be
considered IO.  If for some reason we later need to add another pub socket,
presumably that will be because it has a function distinct from general
publishing, and will have a more readily available descriptive name.


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

kernel_stdin is a fine name, and certainly explicit, as long as the
'kernel_' doesn't propagate to the kernel object itself.
 Kernel.kernel_stdin certainly should never happen, but:

KernelManager.kernel_stdin/KernelStdInChannel
and
Kernel.stdin

will work fine.


>
> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/2ce2dae1/attachment.html>