Function to publish raw/encoded display data

[jlumpe]

Added a display_data function which takes raw/encoded data to display in the front end. The first form accepts a single MIME type and a data string or JSON-able value, the second takes a MIME bundle.

display(::InlineDisplay, ...) methods are updated to use this function instead of explicitly constructing the message and calling send_ipython.

I added a detailed docstring and listed it under the public API in the documentation.

This works when I tested it manually, I don't know how to write a unit test for it though.

[jlumpe]

Closes #934, can use display_data("application/json", json_value).

[jlumpe]

@stevengj does this seem useful?

[stevengj]

I'd rather have this as a method of display

[jlumpe]

@stevengj what exactly would the method be? I feel like this is a somewhat different concept than Base.display, in that the expected arguments are in a different format. display_data is low-level and takes pre-encoded JSON or binary data. display(::InlineDisplay, ...) is high level and takes an argument of any type which is passed to display_dict first.

Another way of looking at it - display(::InlineDisplay, ...) is a method of a function in Base which has an expected behavior, independent of any of the particulars of Jupyter's display system. display_data takes raw display data in Jupyter's specific but well-documented format (MIME bundle). There is some process within display which converts an arbitrary value to a MIME bundle. Right now it's just a call to display_dict, but I think there is room for improvement to the API to make it easier for developers to customize this process for their own types. I'd like to make some contributions here but I think it is necessary to have a separate display_data function as the endpoint in this process, which is called after the MIME bundle has been created but hides the specifics of the kernel -> front end messaging system.

[jlumpe]

@stevengj any thoughts on the above?

[oxinabox]

raw data is never a good term to use,
but here it seems particularly misleading.
that data argument is the output of limitstringmime which means it has already going though a call to rerepresent it.
Which will have for example converted DataFrames to HTML tables, etc etc or anything else that has show(io, mimetype, data) defined on it for any of the registered mime types.

[jlumpe]

How about something like "Publish rich display data to all Jupyter front ends"? I think the rest of the docstring is hopefully pretty clear on the expected format.

[jlumpe]

bump?

[oxinabox]

Could be.
I don't know enough about what this does to say for sure.
And I don't have merge rights here.

[jlumpe]

• Moved new code from src/display.jl to src/inline.jl, where it seems to fit better.
• Accept AbstractDict for metadata argument and check MIME keys
• Significantly improved docstring and added usage examples
• Added ability to update display data at a later time or from a different cell

[jlumpe]

@stevengj Any way you can take another look at this?

[jlumpe]

bump?

[jlumpe]

Latest merge conflicts have been resolved, both display_data and update_display_data methods now call flush_all() before publishing the message (#999).