Should user explicitly init the declarative widget system

[lbustelo]

Currently this project adds an extension to Jupyter that initializes the Widget system on the Notebook page on load. This assumes that the kernel is ready to start accepting COM messages.

In the case of the Scala Kernel, the user must add the jar for the declarativewidget support and explicitly initialize the widget system (e.g. create a com open handler). To support this, we already have code in place on the JS side that runs after each code cell execution to check if the widget system is ready. There is a default of 10 tries (10 cells executed).

I propose that we reconsider how we are initializing and rather have the user explicitly initialize everything by running kernel code.

In python

from urth import widgets
widgets.init()

In scala

import urth._
widgets.init()

The init function would do the following:

1. Make sure that the handler for COM opens on the kernel side is there (in python this is taken care by ipywidgets)
2. Send JS code to the browser that would cause the browser side initialization to take place, basically import some elements and setup the data channel.

[parente]

Would this remove the need to preload polymer and the urth channel stuff on every notebook page, even when widgets aren't used? Would that happen after widgets.init()?

[lbustelo]

@parente that is the point. Nothing gets preloaded until the cell with unit is ran. Maybe only the minimum js would be on all pages.

[parente]

Maybe only the minimum js would be on all pages.

I was after even removing this. For instance, the %matplotlib notebook magic injects all the JS it needs only after this call. Nothing needs to be in Jupyter before then and so it doesn't need to be an extension to Jupyter. It would be very cool if the widgets could reach that point (but I know that would involve some kind of replacement for the urth_import server handler which probably is not replaceable.)

[lbustelo]

We would still need the extension to have the js available for download. But I agree that nothing needs to be preloaded on the browser, if possible.

[lbustelo]

Was doing some experimentation on this. I thought that I could block the kernel from returning from the cell run and orchestrate init though the COM channel. This is not possible because COM channel browser -> kernel is done through the shell channel also.

I also did not see a way to pausing running of cells from the browser side.

I'm going to leave this one open, but will move to work on something else.

[lbustelo]

Thought on how the kernel init code can interact with the browser to cause the init.

Using Comm.

1. Our extension will register a comm target with a name like jupyter_declarativewidgets_init and provide a handler (https://github.com/jupyter/notebook/blob/master/notebook/static/services/kernels/comm.js#L46)
2. The code on the kernel side (widgets.init()) will send a COMM_OPEN message to that target. That should trigger the browser code on https://github.com/jupyter/notebook/blob/master/notebook/static/services/kernels/comm.js#L78 that would then call our handler.
3. There might be an optional handshake to let the kernel side know that all is ready and that could take place through the same COMM channel.

CommManager will then become another dependency that would have to be injected into our env.