[IPython-dev] comm_info_[request/reply] : addition to the messaging protocol

[Sylvain Corlay]

Hi All,

I wanted to come back to the discussion on the request/reply mechanism for
information on currently live comms that we proposed and was discussed at
the last dev meeting. I would be happy to open an IPEP in the wiki on this
subject.

I am posting here because the mailing list is a less transient than gitter
or the hangouts and it helps reaching the broader community that might not
be closely following the GitHub repositories.

Here is some context for those who are new to the subject: when a client is
connected to an already-running kernel (for example in the case of a page
reload in the notebook), it currently has no direct means of knowing what
comms are open in the back-end. If we want it to be able to re-instantiate
front-end counterpart to those comms, a way to retrieve this information
must be implemented.

In the case of the notebook, the front-end can try sending messages to some
comm ids that the browser knows existed at some point because the model ids
of the widget displayed in the notebook are saved in the local storage when
the notebook is saved, but it clearly is insufficient and is essentially a
stab in the dark. This information may be completely outdated.

Hence a natural solution to that issue was to create a new shell message
type, to request the currently open comms from the back-end. Because of the
multi-repository nature of Jupyter, this resulted a the following PRs

*jupyter-client:* https://github.com/jupyter/jupyter_client/pull/34

*ipykernel:* https://github.com/ipython/ipykernel/pull/25    (requires the
previous PR)

*notebook:* https://github.com/jupyter/notebook/pull/166   (requires the
two previous PRs)

*ipywidgets:* https://github.com/ipython/ipywidgets/pull/62 (requires the
three previous PRs)

My initial proposal was to return the list of valid ids because it is what
is required for the use case of widgets. After the discussion in the dev
meeting where Fernando was worried that the schema of the message might
note have been the right one, I changed things a bit and called the
messages *comm_info_[request/reply]*. The reply message a dictionary
containing one key, called `comms`, which itself contains a dictionary of
the form `*{comm_id : target_name}*`

In the case of widgets, the target name is always ipython.widget but not
necessarily in the general case. With this new schema, the whole
information is available and other fields than `comms` could be added to
the *comm_info_reply* message in the future.

There are some workarounds for the lack of such a message in the protocol,
one of which is implemented in the last commit in the PR for ipywidgets.
However, I don't think that such contortions are the way to go. Feedback on
the PRs is welcome. If other users of comms have ideas on this specific
issue, please respond on the mailing list!

Thanks,

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