[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