[IPython-dev] make ipython work over web

[Brian Granger]

Robert,

On Mon, Mar 29, 2010 at 7:47 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-03-28 22:41 PM, Brian Granger wrote:
>> Ondrej,
>>
>> On Sat, Mar 27, 2010 at 12:20 PM, Ondrej Certik<ondrej at certik.cz>  wrote:
>>> On Sat, Mar 27, 2010 at 11:42 AM, Brian Granger<ellisonbg at gmail.com>  wrote:
>>>> Ondrej,
>>>>
>>>>> Ok. Here is my API (so far I have no sessions there):
>>>>>
>>>>> In [1]: import jsonrpclib
>>>>>
>>>>> In [2]: s = jsonrpclib.SimpleServerProxy("http://2.latest.sympy-gamma.appspot.com/test-service/")
>>>>>
>>>>> In [3]: s.eval_cell("2+3")
>>>>> Out[3]: '5'
>>>>>
>>>>> In [4]: s.eval_cell("""\
>>>>>    ...: from sympy import sin, integrate, var
>>>>>    ...: var("x")
>>>>>    ...: integrate(sin(x), x)
>>>>>    ...: """)
>>>>> Out[4]: '-cos(x)'
>>>>>
>>>>> In [5]: s.eval_cell("""\
>>>>>    ...: from sympy import sin, integrate, var
>>>>>    ...: var("x")
>>>>>    ...: a = integrate(sin(x), x)
>>>>>    ...: """)
>>>>> Out[5]: ''
>>>>>
>>>>> In [6]: s.eval_cell("a.diff(x)")
>>>>> Out[6]: 'sin(x)'
>>>>
>>>> OK, if this is the only API you want, it is possible.  BUT, a few points:
>>>>
>>>> * It is completely blocking and synchronous.  We can create such an
>>>> API using 0MQ, but it obviously has limitations.
>>>> * It handles stdout in a completely synchronous manner.  I think we
>>>> can do this too (again limitations apply).
>>>>
>>>> You are going to have to work *very* hard using json-rpc alone to get
>>>> asynchronous stdout/stderr/displayhook.  Here is the design that you
>>>> want that will entirely do what you want:
>>>>
>>>> client<--jsonrpc-->bridge<--0MQ-->kernel
>>>>
>>>> The bridge would be a fully asynchronous 0MQ client and would receive
>>>> the asynchronous 0MQ stdout/stderr/displayhook and simply put them in
>>>> queues.  The bridge would also be a json-rpc server.  with methods
>>>> like:
>>>>
>>>> eval_cell  # submit but don't block. get back an object that would
>>>> allow you to see if the cell was done evaluating.
>>>> complete # again submit but don't return.  Similar logic.
>>>> get_stdout  # get all the stdout that has been written thus far
>>>> get_stderr  # get all stderr that has been written thus far.
>>>>
>>>> You basically want to put a blocking API on top of the asynchronous 0MQ API.
>>>>
>>>> This type of thing should be be too difficult to write using 0MQ and
>>>> we can help out.  If you are serious about this, let me know and
>>>> Fernando and I can come up with a plan.
>>>> We could probably develop this in the pyzmq tree for now.
>>>
>>> My primary concern is the notebook. What is your idea to implement the
>>> asynchronous output update? Let me look at how Sage does it.
>>
>> I would also look at how we are handling it in the 0MQ prototype.  Th
>> challenge is translating that to a browser.
>>
>>> As to json-rpc, it is not blocking, that's just how I like to use it
>>> in ipython. But below the hood, it works exactly as you said, e.g. you
>>> get some id back immediately and then your method gets called (in
>>> pyjamas) when the result is back. I don't know how this is done
>>> internally. I think it's just how AJAX works (the browser calls your
>>> javascript method when the result is back).
>>
>> I need to look at jsonrpclib so better see how it works.  I also see
>> that the author has something that works with tornado.
>
> You may be interested in using the new HTML5 WebSocket API. There is a
> compatibility library for older browsers and Python integration:
>
>   http://orbited.org/

Thanks!  I have not been keeping up with HTML5.  I will talk to the
0MQ team about implementing the 0MQ wire protocol with this.  Orbited
looks interesting, but relies on Twisted, which is going to hold back
the python 3 transition.  This stuff is exactly what we need in the
browser though.

Cheers,

Brian

> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>  that is made terrible by our own mad attempt to interpret it as though it had
>  an underlying truth."
>   -- Umberto Eco
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com