<div dir="ltr">Some time ago, I made a PR to IPython switching to <a href="http://socket.io">socket.io</a>, which required the same basic changes since it only allowed a single connection per page, so I know it's not too hard. We may start to see more pressure as hosted instances, and reconsider the fallback in the future, but at this point, we don't feel that pressure. Wind proper websockets to be sufficiently preferable that we will wait as long as we can before appeasing old, broken, or misconfigured network environments that prevent websockets from working.<div><br></div><div>The majority of notebook users seem to be running as a desktop app via localhost, where websockets are rarely a problem (The nightmare of Sophos AV/firewall on Windows excluded).</div><div><br></div><div>-MinRK</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 10:55 AM, William Stein <span dir="ltr"><<a href="mailto:wstein@gmail.com" target="_blank">wstein@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
> So far we have felt that it isn't worth the complexity cost for us to<br>
> support people that deliberately choose to break the internet. It is not<br>
> like WebSockets is some crazy, insecure, unsupported hack over a weird port.<br>
> It is just different bytes going over the same HTTP/HTTPS socket connection<br>
> and is essentially a formal standard (I know you know this - this is our<br>
> messaging to companies who complain).<br>
<br>
</span>I know -- that's why I switched SMC to pure websockets for a while.<br>
Then I received complaints at a rate of about 2 very desperate users<br>
per week, and these were the people who cared enough to complain<br>
repeatedly.<br>
<span class=""><br>
> Our situation is a bit different though than SMC because most of our current<br>
> users run the notebook on their own computers. This may be something that we<br>
> eventually want to rethink as more people run this in the cloud. However, I<br>
> would like to push back on the companies choosing to break the internet<br>
> really hard before giving in. I am guessing that in most cases, WebSockets<br>
> are broken in enterprise setting not because of some important deliberate<br>
> choice, but rather because people don't understand it and are using default<br>
> settings that disable them (I could be wrong though)....<br>
<br>
</span>In my experience, for some people that's exactly the problem.  For one<br>
person I helped it turned out their specific problem was the Windows<br>
install they had access to had websockets explicitly disabled --<br>
perhaps that was an IT policy.  For other people the problem is<br>
further along the stack (e.g., possibly involving caching).<br>
<br>
Anyway, this change so that "there is a single websocket connection<br>
between the server and client. " makes implementing an alternative to<br>
WebSocket as a fallback dramatically easier, which I greatly<br>
appreciate.<br>
<span class=""><br>
> Our situation is a bit different though than SMC because most of our current<br>
> users run the notebook on their own computers. This may be something that we<br>
<br>
</span>Just curious -- how do you know that most people using IPython aren't<br>
already using it through SMC?<br>
<span class="HOEnZb"><font color="#888888"><br>
William<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Cheers,<br>
><br>
> Brian<br>
><br>
><br>
><br>
> On Thu, Jan 8, 2015 at 10:10 AM, William Stein <<a href="mailto:wstein@gmail.com">wstein@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jan 8, 2015 at 10:04 AM, MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
>> > Alternative notebook frontend authors:<br>
>> ><br>
>> > There is an upcoming change to websocket connections to the notebook<br>
>> > server.<br>
>> > Instead of three websockets per notebook, one for each zmq channel,<br>
>> > there is<br>
>> > a single websocket connection between the server and client. The channel<br>
>> > associated with each message is identified by a channel key in the<br>
>> > message<br>
>> > dict itself.<br>
>> ><br>
>> > Relevant changes:<br>
>> ><br>
>> > url is /channels instead of /shell, etc.<br>
>> > when sending a message, add a channel key with the channel name<br>
>> > ('shell',<br>
>> > 'stdin')<br>
>> > when receiving a message, check the channel key for routing<br>
>> ><br>
>> > -MinRK<br>
>><br>
>> Thanks.<br>
>><br>
>> Of related interest, what the situation involving providing a fallback<br>
>> to websockets?<br>
>><br>
>> I tried to only support websockets connections with SageMathCloud for<br>
>> a few weeks, and immediately ran into many complaints from users who<br>
>> couldn't connect as a result.   This is even with https and so on --<br>
>> it's just a sad fact that in some corporate or otherwise constrained<br>
>> environments that websockets don't work.   By far the best approach I<br>
>> found was to use Primus + Engine.io, which uses websockets if<br>
>> possible, but will fallback to polling.   So this is what SMC does<br>
>> now, and everything works, even for people that don't have websockets<br>
>> as an option... except for IPython-in-SMC of course, which doesn't<br>
>> work.<br>
>><br>
>> Another unrelated issue is that I'm now hardcoding making this change<br>
>> around line 171 of IPython/html/notebookapp.py, since I want to serve<br>
>> the purely static html of IPython from a completely different web<br>
>> server:<br>
>><br>
>>             #static_url_prefix = url_path_join(base_url,'/static/'),<br>
>>             static_url_prefix = '/static/ipython/',<br>
>><br>
>> (Sorry for derailing the thread.)<br>
>><br>
>>  -- William<br>
>><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > IPython-dev mailing list<br>
>> > <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
>> > <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> William Stein<br>
>> Professor of Mathematics<br>
>> University of Washington<br>
>> <a href="http://wstein.org" target="_blank">http://wstein.org</a><br>
>> _______________________________________________<br>
>> IPython-dev mailing list<br>
>> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
>> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Brian E. Granger<br>
> Cal Poly State University, San Luis Obispo<br>
> @ellisonbg on Twitter and GitHub<br>
> <a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
William Stein<br>
Professor of Mathematics<br>
University of Washington<br>
<a href="http://wstein.org" target="_blank">http://wstein.org</a><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br></div>