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

[Kyle Kelley]

Since this is about the message spec specifically for comms (which are also
working on to be used in IHaskell as part of a summer of code project), it
would be nice to post this on the Jupyter mailing list as well.

On Wed, Jul 1, 2015 at 3:35 PM, Chris Colbert <sccolbert at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Kyle Kelley (@rgbkrk <https://twitter.com/rgbkrk>; lambdaops.com,
developer.rackspace.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150701/586d71d3/attachment.html>