I was always under the impression that ZeroMQ <http://jupyter-client.readthedocs.io/en/latest/messaging.html> was the way that Jupyter front-ends communicated to the kernels. I'm not entirely sure how the web-interface fits into that.
That said, this all sounds reasonable. There is really no way to compete with Jupyter, and also no reason to compete. Leveraging all the great work being done makes sense. On Thursday, September 14, 2017 at 12:23:06 PM UTC-4, Edward K. Ream wrote: > > On Thu, Sep 14, 2017 at 11:03 AM, Terry Brown <[email protected] > <javascript:>> wrote: > > Right - my thought is that we want to be able to execute any Jupyter >> cell, be it in Python or javascript or R or Go or whatever. And making >> that happen, from software installation to invocation to exposing >> variables across environments, should be Jupyter's problem, not ours. >> > > Ok. > > Funny how my memory works. I remembered that I have a j.bat file that > starts the jupyter server. It just executes "jupyter notebook". This > serves jupyter pages on http://localhost:8888/ > > So a simple http client should be able to access the data as the jupyter > web page at http://localhost:8888/tree does. > > There may be other ways to access this data, but I would imaging that the > web-based approach would be most natural. > > What do you think? > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
