[IPython-dev] "Freezing" dynamic content with nbconvert, was ANN: Exhibitionist

[Matthias BUSSONNIER]

Hi Yoval, 
Le 7 mars 2013 à 17:48, yoval p. a écrit :

> Hi,
> 
> I've been giving matthias's comment some thought re nbviewer support
> for javascript views, and also considered the intention of disabling javascript
> due to security-concerns.
> 
> Here is a solution to both issues that I'd like to suggest:
> 
> There's a need to separate static HTML from HTML bearing
> javascript which might only be renderabe dynamically, call it dynamic HTML.
> 
> My suggestion is that the display protocol be modified  so that the semantics of
> `_repr_html_` would mean static HTML only, and a new `_repr_jshtml_` (however named)
> magic method would be supported, under which objects would implement
> dynamic views.
> 
> This provides the following benefits:
> - Objects can provide HTML representation of themselves suiting
> the environment they are in. It's the front end that chooses the
> representation it supports. So there will be no further need to sniff
> qtconsole vs. IPNB via `get_ipython().config`.
> In particular, nbviewer could leverage this to allow even dynamic views
> to gracefully degrading in order to cooperate.
> - For security reasons, the use of '_repr_jshtml_' view by IPYthon would be behind
> an opt-in mechanism, and the static  `_repr_html_` would be sanitized/sandboxed.
> 
> The IPython.core.display functions could be extended accordingly to
> obey the currently active security policy.
> 
> Thoughts?

What you describe look IMHO to much to the current _repr_html_/_repr_javascript_, we had quite some time to think about it, 
and something in those line was my first idea, but dealing with displaying javascript is both much more complicated than it looks.
We are also  certain that we can have a more general approach.

(Keep in mind that, thinking of the display protocol as only html/js notebook/qtconsole is also much too restrictive)

In short, we believe using _display_json_ is the right way and is enough. 

Most of the time, when you display js, the only thing you want to send are data that need to be interpreted.
Javascript plugin should be js files loaded as extension, you shouldn't need to display generated code. 
This allow also to depend on other installed plugin without having to embed lib like jQuery etc at every call.

In framework like chromium embeded, you cannot in any way execute code that are in script tag. The js
**have to** be part of the application at launch time.

With the architecture we planed, rewriting _display_javascript_ should be totally possible as simple small plugin
it will just not be supported.

As for nbviewer, if there is a _repr_json_ , nothing prevent it from using it in html to have dynamic represent, 
but the same json could be use to make a Tikz representation in latex, or even multiple plugin could be able to interpret the same json.

So after long repletion, I am convince that json-repr is the way to go.

We'll still consider the suggestion of course, and discussion are welcomed. 

-- 
Matthias









> 
> Yoval
> 
> Matthias BUSSONNIER write:
> > Hi y-p ! 
> > 
> > Look really nice ! 
> > 
> > Did not have time to look into the source right now, but I'll definitively will. 
> > Do you think  the data exchanged with the kernel in some cases could be store either in the metadata of cells, 
> > or in the Json representation of displayed object ? 
> > 
> > If we do this and by carefully crafting the "js plugin"  they could be loaded by nbviewer and read sone data in the dom injected. 
> > Which would allow a limited interactivity on nbviewer. 
> > 
> > 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. 
> > 
> > -- 
> > Matthias
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130307/de133230/attachment.html>