[IPython-dev] make ipython work over web
Sat Mar 27 12:57:06 CDT 2010
> I would like both the browser and the command line to use the exact
> same API, so that I can easily test the server part using unittests.
I am not quite sure I understand what you mean by the "same API". Do you mean
the wire level JSON messages? The programatic API (classes+methods,
etc), or something else.
I don't that what you want is possible actually though. The reason is
that a browser/server architecture is pure request/reply (1 way only).
You can fake server->browser requests but it still required quite a
bit of magic on server and browser sides.
With our 0MQ based kernel, the kernel opens two types of 0MQ sockets:
1. XREP. This is a request reply socket that multiple clients can use
to interact with the kernel in a traditional request/reply manner.
This is how a client can execute code, do tab completion.
2. PUB. This is a publication socket. It is one way outbound from
the server to the client. You can think of a PUB socket as a radio
transmission. The client subscribes to topics on the socket (using a
SUB socket) and gets the messages that matches the subscribed topics.
We use the PUB channel for asynchronos
Thus a frontend has to be able to:
* Do traditional request/replies.
* Watch for incoming messages on the PUB/SUB channel.
It has to do this at the same time and the only sane was of doing that
is with an event loop. Our current frontend.py does not use an event
loop, and thus has to use subtle and buggy logic to fake it.
Hope this helps more. But it would help if you could explain what you
mean by the "same API".
>>> 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?
>> Exactly. We are more than willing to change our JSON message format
>> if it makes sense.
>> Have a look at how we are structuring our messages. We thought about
>> it quite a bit so it could be general and extensible.
> That is not a big deal for me either to change the format. I am using,
> what appears to be the standard way to handle json-rpc, e.g. invoke
> methods over it, it works for me, and I can always change it later if
I will look more at the JSON RPC format, but I doubt it will work
entirely for us. This is because the messages sent on the PUB/SUB
sockets are not of the request/reply format.
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
More information about the IPython-dev