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">&lt;<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>&gt;</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 &lt;<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>&gt; wrote:<br>

&gt; The connect/shutdown/abort logic does seem to to together, but kernel<br>
&gt; attribute access seems to go with the XREP-a things.  For the parallel<br>
&gt; stuff, the different between these two types of XREP channels makes<br>
&gt; sense, because they are talking to different processes.  But here, it<br>
&gt; is just 1 process, so I am not sure it makes sense.  I am a little<br>
&gt; 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&#39;s true that one can get the kernel via<br>
&#39;ip = get_ipython()&#39; and start working on it, that&#39;s not the &quot;regular&quot;<br>
mode of operation in most user activities.<br>
<br></blockquote><div><br></div><div>But wouldn&#39;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&#39;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&#39;t be too<br>
big of a deal.  I do agree with you that we don&#39;t want these things<br>
growing like dandelions, but I don&#39;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">
&gt;&gt; - PUB: &#39;iopub&#39;.  This publishes the i/o streams.<br>
&gt;<br>
&gt; But we publish more than the io streams on this channel.  In reality,<br>
&gt; 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, &#39;iopub&#39; seemed like a reasonable, and short, way to<br>
describe &#39;publish all i/o activity produced by the kernel&#39;.  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&#39;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&#39;t convince you, I&#39;m happy to<br>
reconsider (though I&#39;d like to find something a little shorter than<br>
side_effects, we&#39;re likely to use these names a lot everywhere...).<br>
<div class="im"><br>
&gt;&gt; - REQ: &#39;kstdin&#39;. This is the socket that forwards the kernel&#39;s stdin<br>
&gt;<br>
&gt; I think he &quot;k&quot; is a bit too short and confusing.  Maybe kernelstdin?<br>
&gt; Or just stdin?<br>
<br>
</div>Yes, the k alone didn&#39;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&#39;s a bit long but this one isn&#39;t likely to be used<br>
super-often, and I think it&#39;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>