Hi,<br><br>&gt; But thanks for your feedback and ideas: only if we can explain and<br>
&gt; clarify our thoughts sufficiently to justify them, can we be sure that<br>&gt; we actually understand what we&#39;re doing.<br><br>Hehe, I can imagine you (or others reading this thread) start to think I&#39;m stubborn. Well I&#39;m a bit of a purist at times and I keep to my opinion unless I&#39;m convinced by good arguments :)  But hey, its your project, so please let me know if you&#39;ve had enough of my criticism.<br>
<br>So here&#39;s a little more ...<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
&gt; * I really think you can do with less sockets. I believe that the (black)<br>
&gt; req/rep pair is not needed. You only seem to use it for when raw_input is<br>
&gt; used. But why? When raw_input is used, you can just block and wait for some<br>
&gt; stdin (I think that&#39;ll be the execute_request message). This should not be<br>
&gt; too hard by replacing sys.stdin with an object that has a readline method<br>
&gt; that does this. If two users are present, and one calls raw_input, they can<br>
&gt; both provide input (whoever&#39;s first). To indicate this to the *other* user,<br>
&gt; however, his prompt should be replaced with an empty string, so his cursor<br>
&gt; is positioned right after the &lt;text&gt; in raw_input(&#39;&lt;text&gt;&#39;).<br>
<br>
</div>Keep in mind that the direction of those sockets (the normal xreq/xrep<br>
pair for client input and the req/rep for kernel stdin) is opposite,<br>
and that&#39;s because they represent fundamentally different operations.<br></blockquote><div><br>I get that, but I&#39;m not sure whether this is correct/necessary for the 
raw_input. In the original Python interpreter, raw_input just reads from
 stdin, the same stream that&#39;s used for executing commands. The 
interpreter just waits for the next &quot;command&quot;, which is then interpreted
 as text, rather than executing it. In a shell, this idea works quite 
well.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I&#39;m not worried about &#39;too many sockets&#39;, I would worry about having<br>
more sockets, or *less* sockets, than we have separate, independent<br>
concepts and streams of information.  It seems that now, we do have<br>
one socket pair for each type of information flow, and this way we<br>
only multiplex when the data may vary but the communication semantics<br>
are constant (such as having multiple streams in the pub/sub).  I<br>
think this actually buys us a lot of simplicity, because each<br>
connection has precisely the socket and semantics of the type of<br>
information flow it needs to transfer.<br><div class="im"></div></blockquote><div><br>So in your words, I believe that raw_input should actually be the same data stream as the commands.
Sure, because you now have a GUI at the other end, you 
could create a pop-up dialog for the user to input the requested text. 
But is that really better/nicer? It can also be a bit intrusive. <br><br>However, my main argument against this approach is what I already mentioned in the previous e-mail: whatever client executes raw_input, the data should be input at the &quot;main client&quot; (the client having the particular socket connection). What if that happens to be the PC at work, while you&#39;re in the bar? <br>
<br>Concluding: I see no reason why commands can be executed by all clients, while a response to raw_input can only be given from one.<br><br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
&lt;snip stupid idea to get stdout stderr etc via a req/rep pattern&gt;</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
</div>Rather than forcing the kernel to store all that info and play back<br>
multiple data streams, I&#39;d separate this (valid) idea into its own<br>
entity.  Someone could easily write a client whose job is simply to<br>
listen to a kernel and store all streams of information, nicely<br>
organized for later replay as needed.  Because this client would only<br>
be storing the string data of the messages, there&#39;s no danger of<br>
making the kernel leak memory by asking it to hold on to every object<br>
it has ever produced (a very dangerous proposition).  And such a<br>
logger could then save that info, replay it for you, make it available<br>
over the web, selectively SMS you if a message on a certain stream<br>
matches something, etc.<br>
<br>
For example, with this design it becomes *trivial* to write a little<br>
program that subscribes only to the pyerr channel, monitors<br>
exceptions, and sends you an SMS if an exception of a particular type<br>
you care about arrives.  Something like that could probably be written<br>
in 2 hours.  And that, thanks to the clear separation of information<br>
flow semantics across the various channels, that make it very easy to<br>
grab/focus only on the data you need.<br></blockquote><div><br>You&#39;re right. That seems very natural. However, I&#39;m still a little concerned about when a user connects to a kernel that&#39;s running extension code and is therefore unresponsive. This would immediately become clear to him/her if he saw the preceding stdout/stderr. <br>
<br>What about storing these messages (to be send from the PUB socket) at the kernel? I mean store the string messages, not the objects used to create them (i.e. no holding onto large objects). You could then send this history when a client connects. Something like &quot;Hi there, this is what we&#39;ve been doing so far.&quot;. <br>
<br>Cheers,<br>  Almar<br></div></div>