Boy I am busy these days...continuing on...<div><br><div class="gmail_quote">On Wed, Nov 3, 2010 at 10:28 PM, Fernando Perez <span dir="ltr"><<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
> The connect/shutdown/abort logic does seem to to together, but kernel<br>
> attribute access seems to go with the XREP-a things. For the parallel<br>
> stuff, the different between these two types of XREP channels makes<br>
> sense, because they are talking to different processes. But here, it<br>
> is just 1 process, so I am not sure it makes sense. I am a little<br>
> concerned about un-needed proliferation of channels.<br>
<br>
</div>Our reasoning for putting attribute access there was to keep the -a<br>
socket strictly for things the user would normally see in his regular<br>
namespace, and -b for things that had to do with manipulating the<br>
kernel object itself. While it's true that one can get the kernel via<br>
'ip = get_ipython()' and start working on it, that's not the "regular"<br>
mode of operation in most user activities.<br>
<br></blockquote><div><br></div><div>But wouldn't both XREP channels probe the users namespace?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And Min brought up a compelling point for wanting the separate kernel<br>
control channel: so that things like abort commands can jump to the<br>
front of the queue. This will become more important once the web<br>
notebook makes it natural to queue up multiple cells for execution,<br>
for example.<br>
<br></blockquote><div><br></div><div>Yes, that does make sense. But then I think that the control channel should *never* touch the user's namespace.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And once we update the connection logic to use the mechanism Min has<br>
with a single socket for initial connection and all others<br>
auto-negotiated after that, having one more socket shouldn't be too<br>
big of a deal. I do agree with you that we don't want these things<br>
growing like dandelions, but I don't think we have too many more in<br>
store, to me this seems like a reasonably complete coverage of what we<br>
need.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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...</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>> - PUB: 'iopub'. This publishes the i/o streams.<br>
><br>
> But we publish more than the io streams on this channel. In reality,<br>
> it is for sideeffects, so would that name make sense.<br>
<br>
</div>We thought about that but it seemed a little too long... And we looked<br>
at the actual list of what goes there, right now we have:<br>
<br>
# Streams (stdout, stderr, etc)<br>
# Python inputs<br>
# Python outputs<br>
# Python errors<br>
# Kernel status<br>
# Kernel crashes<br>
<br>
It seemed like most of this was the kind of thing that normally shows<br>
up on i/o streams at a console/log, so while not literally being<br>
stdout/err, 'iopub' seemed like a reasonable, and short, way to<br>
describe 'publish all i/o activity produced by the kernel'. I/O is<br>
more or less by definition a side effect (which is why functional<br>
languages typically have to do something a bit odd to provide it, as<br>
it doesn't really fit into a purely functional paradigm)...<br>
<br></blockquote><div><br></div><div>I just think that IO is too limiting because of our moving the payload to this channel. So maybe:</div><div><br></div><div>datapub?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
But if this justification doesn't convince you, I'm happy to<br>
reconsider (though I'd like to find something a little shorter than<br>
side_effects, we're likely to use these names a lot everywhere...).<br>
<div class="im"><br>
>> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin<br>
><br>
> I think he "k" is a bit too short and confusing. Maybe kernelstdin?<br>
> Or just stdin?<br>
<br>
</div>Yes, the k alone didn't seem very nice. kernel_stdin? (In general, I<br>
think we should avoid run-in words without underscores as much as<br>
possible). It's a bit long but this one isn't likely to be used<br>
super-often, and I think it's a good idea to keep explicit the fact<br>
that this one is a special socket handling something from the kernel,<br>
rather than client-side stdin.<br>
<br></blockquote><div><br></div><div>Yes, I think that kernel_stdin is better.</div><div><br></div><div>Cheers,</div><div><br></div><div>Brian</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thanks for the feedback!<br>
<br>
Cheers,<br>
<font color="#888888"><br>
f<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Brian E. Granger, Ph.D.<br>Assistant Professor of Physics<br>Cal Poly State University, San Luis Obispo<br><a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a><br>
<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
</div>