[IPython-dev] make ipython work over web
Sat Mar 27 02:10:13 CDT 2010
Hi Fernando and Brian!
this looks very exciting! Some comments below:
On Fri, Mar 26, 2010 at 8:17 PM, Brian Granger <firstname.lastname@example.org> wrote:
> Yes, we definitely want people to be able to use IPython in this
> manner. As Fernando mentioned, earlier this week he and I did a short
> 2 day sprint to create a first prototype of a 2 process
> kernel+frontend model using 0MQ. It worked even better than we hoped
> and we are convinced that this is the future for IPython. The idea is
> that the IPython "kernel" would run in a separate process and listen
> on a few 0MQ sockets. A "frontend" (which could be a web server)
> would talk to the kernel using JSON based messages and a thin 0MQ
> based API.
>> it just occurred to me that it'd be a cool idea to be able to use
>> ipython as the Sage/FEMhub notebook, in particular, you would use it
>> just like regular ipython in the terminal (only at the beginning you
>> would log in) and it would interface the Sage/FEMhub server over some
>> API (I am playing with json-rpc api at ) and I guess it would
>> always create a new worksheet and only allow to add new cells at the
>> bottom (which is the way ipython works).
>> So it will be a nice thin client. I don't know how this fits in the
>> recent ipython refactoring. Essentially I am trying to figure out some
>> nice API for evaluating cells, doctests ("?"), code inspection ("??"),
>> code completion ("TAB"), and it takes some time to always implement
>> this in the web notebook directly, so I want to play with this in a
>> simple terminal client.
> Currently this new stuff is just a prototype. Two things (still not
> small) need to happen:
> * We need to make the prototype kernel work for real with IPython.
> * We need to solidify the frontend API so that others can start to use it.
> But, both Fernando and i are feeling that these things are doable now
> whereas before the 0MQ stuff, it felt semi-hopeless.
>> Essentially almost all ipython features could work remotely over some
>> API. And the web notebook would then use the exact same interface, so
>> it should be easy for people to write the web notebooks.
> This is our vision.
>> I guess some of you must have thought about this, but I am just
>> posting it here, as I like this idea (so far).
> I definitely encourage you to have a look at the demo Fernando linked
> to. It does some very non-trivial things that will be important for a
> web based interface. The most important thing is how it handles
> stdout/stderr/displayhook asynchronously.
> In the demo try:
> import time
> for i in range(10):
> print i
> i**2 # this triggers displayhook
> The print and the displayhook will happen async. And if there are
> multiple frontends connected, they will *all* see the results. I
> bring up these things because I saw that the sympy alpha does not
> handle printing asynchronously like the Sage notebook.
Indeed it doesn't yet. Let me see how you did that. I would imagine
that instead of using StringIO for stdout, I can use my own subclass
of it, that would send some stuff the client on the fly. I have to
study how the sage notebook did that too.
When compiling pyzmq, I had to apply the following patch:
diff --git a/setup.py b/setup.py
index 86283c6..7d9f1fc 100644
@@ -49,7 +49,9 @@ else:
zmq = Extension(
sources = [zmq_source],
- libraries = [libzmq]
+ libraries = [libzmq],
Is there some way to do this easier? I've installed zmq into ~/usr.
In general it looks really awesome, the tab completion works fine. I
am now figuring some API for handling sessions and logins. How do you
way to handle that? The kernel would return you some hash (key), that
you can (=have to) use in subsequent RPC method calls to authenticate?
Let me study how cookies work.
I will try to get things working too, and of course I'll be happy to
change the API, so that it's ipython compatible, once you figure it
out and stabilize it.
So in order to use your stuff, I would use json-rpc to communicate
between the browser and the server, and then the server would use
pyzmq to communicate between the server and the ipython kernel?
More information about the IPython-dev