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

Fernando Perez fperez.net@gmail....
Wed Mar 21 00:08:30 CDT 2012


On Mon, Mar 19, 2012 at 5:51 PM, Brian Granger <ellisonbg@gmail.com> wrote:
> On Mon, Mar 19, 2012 at 5:27 PM, hugo <hugo@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...

Cheers,

f


More information about the IPython-dev mailing list