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

[Chris Colbert]

I'm +1 on the idea, but -1 on the proposed format of the message. It's
really difficult to specify a schema for the message when the keys of the
message are dynamic. In this case, the key `comm_id` can be anything, which
makes validating the message difficult, and defining a corresponding object
type (other than a hash table) for the message impossible.

If instead you list the active comms as an array of pairs, it becomes very
easy to both define the schema for the message, as well as handle the
message on the client-side. Something like:

`{ type: 'comm_info_reply', comms: [ { id: 'foo', target: 'ipython.widget'
}, ... ] }`


On Sat, Jun 27, 2015 at 11:46 PM, Sylvain Corlay <sylvain.corlay at gmail.com>
wrote:

> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150701/ff8296a5/attachment.html>