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

Chen-Shan Chin cschin at infoecho.net
Wed Mar 21 15:04:26 EDT 2012


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