[IPython-dev] experiment - remote execution of jquery and d3 code into the browser via ipython

Chen-Shan Chin cschin at infoecho.net
Tue Mar 27 02:06:21 EDT 2012


Yet another demo, http://dl.dropbox.com/u/69208751/ipython_d3_word_ladder.mov 

I think it will be cool to be able to use ipython notebook to build such level of interactivity for some exploratory data analysis. (not data intensive, but interactive rich or 3D stuff) 

While most things that has been shown by some of us are currently d3.js centric, I think what we will like to see is to embrace as much as possible other cool javascript libs (e.g. http://mrdoob.github.com/three.js/ for 3D visualizations) .

--Jason


On Mar 21, 2012, at 12:04 PM, Chen-Shan Chin wrote:

> 
> On Mar 20, 2012, at 10:08 PM, Fernando Perez wrote:
> 
>> On Mon, Mar 19, 2012 at 5:51 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>> On Mon, Mar 19, 2012 at 5:27 PM, hugo <hugo at continuum.io> wrote:
>>>> ah - interesting, I didn't quite understand it at first.
>>>> 
>>>> I think that would work, however in the d3 case, I think performance
>>>> would be an issue, d3 uses callbacks for everything.  for a scatter
>>>> plot, each circle needs at least 2 callbacks, one for x coordinate, one
>>>> for y coordinate, that would be one round trip communication per point!
>>>> for local work, this might be ok, but it probably won't work in a
>>>> traditional client server setup, especially if you get many points.
>>>> 
>>>> I think for me - the complexity involved in this is enough to convince
>>>> me that this is the wrong approach.  It was an interesting experiment
>>>> but I'm going to give up on this path, I think a preferable route is to
>>>> implement higher level plots (scatter, lines, image plots, etc..) which
>>>> only take json serialiseable data as args, and then just call those from
>>>> ipython.
>>> 
>>> I strongly agree with this assessment.  In general we are -1 on adding
>>> new web socket connections and trying to manage Javascript/Python
>>> communications at a fine grained level.  Things like interactive plots
>>> should simply take JSON data at the beginning and they work with it on
>>> the client side.
>> 
>> That's my take on it too, esp. given how intensely callback-based d3
>> seems to be.  Even for localhost work, the fact that we'd be creating
>> thousands of callbacks that become
>> js-websockets-python-stringifiedjs-websocket-js monsters would
>> probably make anything non-trivial unusably slow.
>> 
>> But thanks Hugo for this experiment!  It's great to start seeing with
>> practical tests the boundaries of the problem, so that we can plan out
>> what will be the most fruitful approaches to enable.  We really want
>> to simply refactor things in ipython so that *users* can start
>> creating any kind of js-based interactive display they want, instead
>> of us welding any specific approach to ipython itself.
>> 
>> I think for now we've settled on the approach Brian outlines above as
>> the most sensible path forward, eventually adding capabilities for
>> incremental update of the data on the client.  Clients would provide
>> most interactivity with locally cached data, only requesting new
>> information from the python process on an infrequent basis as
>> thresholds of resolution or viewport are crossed.
>> 
>> The one thing that will *not* be good for is real-time display of
>> data, where you are actually pulling data as fast as it can be
>> captured.  Something like Peter Wang's Chaco demo with real time audio
>> capture and spectrogram would require a ton of communication across
>> the process boundary that I'm a bit doubtful will work well enough
>> with that many layers in between...
>> 
> 
> 
> I think the html notebook can not currently support high through network traffic for large
> amount data transfer. And it is probably true for most web based visualization.  What I 
> think a general approach is to enable good API for two way communication to enable exchange
> information in the browser (javascript objects) and the ipython kernel (python objects), such
> a more convient way to develop interaction-rich visualization all within ipython notebook 
> environment. 
> 
> For example, if I need a input-text box, I like to response the "on_change" javascript event
> with a python code. I will like to able to do something like this
> 
> 
> ## create a test input text box
> input_style = {"width":"240px"}
> i1 = vis.InputWidget(name = "input_1",
>                     parent = "plot_area",
>                     style = input_style,
>                     value = "try this out",
>                     vis = vis_display)
> 
> def onchange(self, *argv, **kwargv):
>    self.update_value()
> 
> vis.set_action(i1, "onchange", onchange) 
> 
> And when the event "onchange" of the input-text html element is trigger, the "sefl.update_value()" python code is executed.
> 
> 
> It is totally possible to do such thing in the current 0.13-dev using the current ipython websocket/zmq channel. 
> I have to monkey patched a numbers of thing on intercepting io_pub message that is not originally from
> a code_cell. With those patches, one can create any html based visualization with one's favorite
> javascript library.  
> 
> (A notebook that I am working on can be download from https://github.com/cschin/IPython-Notebook---d3.js-mashup/blob/master/inb_vis_widget_exp.ipynb , It has the instruction on how to monkey patch the 0.13-dev to
> make it work. I will write more about this later too.)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




More information about the IPython-dev mailing list