[IPython-dev] make ipython work over web
Sat Mar 27 12:27:53 CDT 2010
On Sat, Mar 27, 2010 at 10:04 AM, Brian Granger <firstname.lastname@example.org> wrote:
>> 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.
> Yep that is how we handle it.
>> When compiling pyzmq, I had to apply the following patch:
>> diff --git a/setup.py b/setup.py
>> index 86283c6..7d9f1fc 100644
>> --- a/setup.py
>> +++ b/setup.py
>> @@ -49,7 +49,9 @@ else:
>> zmq = Extension(
>> sources = [zmq_source],
>> - libraries = [libzmq]
>> + libraries = [libzmq],
>> + include_dirs=["/home/ondrej/usr/include"],
>> + library_dirs=["/home/ondrej/usr/lib"],
>> Is there some way to do this easier? I've installed zmq into ~/usr.
> We recommend adding those paths to setup.cfg, but it is the same info.
>> 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.
> We don't handle it yet, but here is our plan. When the kernel starts
> it will create a security key that look like this:
> The last part is the security key. Clients that want to connect will
> have to include the security key in each message. For user/password
> style login and sessions I would implement that at the browser level.
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 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
More information about the IPython-dev