Support for custom mime-renderers

[Madhu94]

From #481, I don't think custom mime types are supported in nbviewer and you should send an additional payload of text/html or some standard mime to get outputs to render on nbviewer.

Could we not do something similar to what was done for embedding widgets ? Authors can publish their renderers on npm/unpkg and nbviewer can require those. The name of the renderer module (say MyRenderer has to be stored in the notebook somewhere, we require that module and call a known method on it (say MyRenderer.render_mime).

What do you think ?

jupyter/nbviewer#263 is similar, but deals with the generic set of nbextensions and not just mime types.

[mpacer]

Hrm, I have vague concerns about the security implications of this… but I am not able to articulate them well.

@Carreau @rgbkrk @minrk do you see any obvious issue with this?

[minrk]

There are security implications, depending on where the HTML is served. Not for nbviewer itself, because the nbviewer domain by design shouldn't have access to anything interesting (nbviewer hosted behind JupyterHub would be a very different story). Just like HTML/js output, this should be fine as long as there's a way for particular users to disable and/or whitelist renderers. I'm not sure what the defaults should be.

[Madhu94]

the nbviewer domain by design shouldn't have access to anything interesting

Yes, makes sense. But don't the same security concerns apply for embedding widgets? The default is unpkg.com and I think even thats' configurable now.

[minrk]

Yes, 100%. This ought to be in the same class as the custom widgets support.

[rgbkrk]

I think there's two distinctions for custom mimerenderers here -- those that should be supported by nbconvert by default that are now default in jupyterlab and nteract (vdom, vega), and those which would require vetting.

[Madhu94]

As I see it, the benefits are - no need to save duplicate data in the notebook and no need to bother with a fallback to <script> tags and html

those which would require vetting.

Do you think loading renderers would be useful if this was configurable with a whitelist as proposed by @minrk ?

[mpacer]

We also should consider if/how this should apply to non-html output. For example, for LaTeX we have a longstanding concern that we have no good way to convert raw-html to LaTeX; would this apply to the ePub exporter(which I believe we were going to base on the html exporter); how should it play with slides?

The second concern is that while we can support vega and vdom as jupyter approved what the real solution here would seem to be would be some kind of plugin/entrypoint-like solution on the nbconvert side. That way library’s at least have an opportunity to support non-html ways of handling exports if they want to (for with a js renderer would never suffice).

I could imagine running custom mine types through a Jinja filter function that uses entry points to allow 3rd party libraries to register entrypoint functions that will be iterated over until a match is found for the mime type and current output type. It would probably make sense to default to removing the content if it has no renderer for the output format.

Does anyone see glaring issues with that approach?

[akhmerov]

I could imagine running custom mine types through a Jinja filter function that uses entry points to allow 3rd party libraries to register entrypoint functions that will be iterated over until a match is found for the mime type and current output type. It would probably make sense to default to removing the content if it has no renderer for the output format.

This would require restructuring the skeleton template, right? (one would make the head depend on the contents of the notebook.)

[MSeal]

Likely it would require some thought in the template design, yes. I'm not opposed to improvements to the template approaches but it might make the PR a bit harder to implement that it otherwise would be to accommodate the various usage patterns correctly with such a change.