[IPython-dev] ANN: Exhibitionist - integrating HTML/JS UIs into interactive python work

[Jason Grout]

On 3/6/13 5:51 PM, Brian Granger wrote:
> Hi,
>
> On Wed, Mar 6, 2013 at 2:36 PM, yoval p. <y-p at gmx.com> wrote:
>> Here's hoping mailman picks this up into the correct thread...
>>
>> Hi Brian/Matthaias,
>>
>> Thanks for the heads up.
>>
>> I'm looking forward to superior functionality being available
>> in IPython, though your roadmap is unclear on whether
>> this will actually land late this year or in 2014.
>>
>> To reiterate, The only IPython functionality needed
>> is the ability to load and view remote HTML pages, and that only
>> as a substitute to using a separate browser window.
>> Is that really something you're planning to disallow?
>> If so, I strongly urge you not to throw away a feature that makes
>> IPython-notebook as powerful as the web.
>>
>> Wouldn't an Opt-in mechanism be sufficient?
>>
>> As for strong assumptions, The only assumption I'm really making
>> is that there's a network connection between the front-end and
>> where the kernel is.
>
> That is the critical assumption that we make absolutely no promise to
> maintain.  Right now the notebook server happens to run on the same
> host as the kernel, but that is not a requirement in any way.  You
> should assume that the kernel could be running on a different host
> that has absolutely no network connectivity to the outside world other
> than the notebook server host.  The main IPython message architecture
> is designed precisely to allow the kernel to run anywhere - that is
> why we say these are the official way of talking to the kernel.
>
> Cheers,
>
> Brian
>
>> Cross-origin issues are already addressed with
>> built-in JSONP and CORS support.
>> Could you elaborate on how this assumption might be violated in the future?
>> Surely a user working on his laptop on a local file, with a local kernel
>> should be able to access local urls. I'm less interested in other
>> use-cases, and frankly don't have the resources to pursue them.
>>
>> I'm trying to keep things generic, so hopefully views will be
>> easily portable to the new architecture when it arrives.
>>
>> I've started work on a crossfilter (http://square.github.com/crossfilter/)
>> based
>> "lasso" UI, that allows you to graphically filter a python dataset by
>> selecting
>> points across different dimensions, and pick up the filtered dataset back in
>> python.
>> Unless I hit a wall, there should be a demo up in a couple of weeks.
>>
>> stay tuned,
>> Yoval
>>
>>
>>
>> Matthaias Bussonnier Wrote:
>>> Do you rely on display_javascript for the initial loading of javascript ?
>>> or inject <script> tag in a display HTML
>>
>>> If you do , this can be problematic in the future.
>>
>> Brian Granger Wrote:
>>
>>> This is really cool to see work like this happening.  Very nice!
>>>
>>> I wanted to update you on the development situation with IPython that
>>> may affect your code:
>>
>> This is really cool to see work like this happening.  Very nice!
>>
>> I wanted to update you on the development situation with IPython that
>> may affect your code:
>>
>> * We plan on starting to work on creating a nice architecture for
>> interactive JavaScript widgets, in late summer.
>> * This architecture will enable all of this to be done without any
>> additional server logic.
>> * Using additional server logic as you have done is not officially
>> supported.  What I mean by this is that the notebook architecture may
>> change in a way that makes it impossible to do this type of thing.
>> The problem is that you have made some strong assumptions about where
>> the notebook server, kernel and your server are running.  The
>> preferred way of getting data back and forth between python and the
>> browser is to use our message channels.  Currently these channels are
>> not sufficient for what you want to do, but after are work later this
>> year, they will be.
>> * Because of security issues are are moving away from the notebook
>> being able to execute dynamically generated javascript code.  We will
>> replace this with a javascript plugin system that is more secure.  You
>> will have to rewrite things when this happens.
>>

I'll just note that if IPython had a way of registering python handlers 
for custom messages from the browser, then we'd have "official" ways of 
maintaining a connection between the browser and kernel.

Jason