[IPython-dev] make ipython work over web

Ondrej Certik ondrej at certik.cz
Sat Mar 27 13:27:53 EDT 2010

On Sat, Mar 27, 2010 at 10:04 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> Ondrej,
>> 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(
>>     'zmq._zmq',
>>     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
>> handle those? Sagenotebook uses cookies I think. What is the canonical
>> 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:
> tcp://ip:port/324lkj4fss90lkj234l5sdflj4
> 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 mailing list