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

Tue Nov 16 21:57:50 EST 2010

On Tue, Nov 16, 2010 at 3:51 PM, MinRK <benjaminrk at gmail.com> wrote:

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

Ok, I was under the (incorrect) impression that kernel properties could
touch the namespace.  This is less of an issue then.

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

My misunderstanding.

>
>>
>>> 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 know that IO broadly defined includes things like plots.  But there are
some types of things that stretch the notion of IO pretty far. But I am
mostly fine with iopub as well as datapub.

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

In this case, I think that pub is pretty good.  The only issue is if we
later have another pub channel like for logging.  So maybe iopub is best.

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

Sounds good.

Brian

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

-- 
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/03f0aa08/attachment.html>