These are chat archives for ipython/ipython

26th
Sep 2016
Malkhara
@Malkhara
Sep 26 2016 03:47
Hey
Min RK
@minrk
Sep 26 2016 09:19
@mhat this is a fine place. That's a tricky question. If you want it to work right now, you could do it with the Widgets, where you can define your own message sub-protocol.
With widgets, you could have your own messages sending 'part 1 of 12', etc.
Jason Grout
@jasongrout
Sep 26 2016 12:10
@minrk has a good point. Especially in JupyterLab, you could naturally do this with comms or with widgets, and basically you take responsibility for rendering the output when all the pieces come in (or partially rendering it, if you can...).
Min RK
@minrk
Sep 26 2016 12:15
There may well be room for such a change in the base protocol (it has come up once before, to my knowledge), but it might be challenging, and the base protocol is a pretty conservative, slow-moving thing.
Jason Grout
@jasongrout
Sep 26 2016 12:22
We sort of have precedence for it, in that we combine the stderr/stdout message blocks. That's more of an optimization, and different because each piece could stand on its own. But the final result is a block that trickled in over time...
You could imagine a new output renderer that was registered that preserved state, and had a new mimetype of application/jupyterlab-partial-mimetype
and encoded both the target mimetype and the part number.
or you may not have to preserve state if you had access to all of the current outputs in that particular cell.
(probably want to do application/jupyterlab-partial-mimetype+json to be able to encode the information better...)
Jason Grout
@jasongrout
Sep 26 2016 12:27
But perhaps a better way is to do the decimation and summarization on the server side, and have a dynamic communication link with comms or widgets that would display the summarized data in the browser.