[IPython-dev] comm_info_[request/reply] : addition to the messaging protocol
Sylvain Corlay
sylvain.corlay at gmail.com
Thu Jul 2 14:23:15 EDT 2015
I updated the PRs with the suggestions of Min regarding the schema for the
reply messages:
```
Message type: ``comm_info_request``::
content = {
}
Message type: ``comm_info_reply``::
content = {
# A dictionary of the comms, indexed by uuids.
'comms': {
uuid: {
'target_name': str,
},
},
}
```
Sylvain
On Wed, Jul 1, 2015 at 5:31 PM, Sylvain Corlay <sylvain.corlay at gmail.com>
wrote:
> The use case that we face at the moment is to check if ids are valid comm
> ids, however, it is likely that in the future, we perform other operations
> on each comm.
>
> I will box the comm target in a dictionary for each comm id as suggested
> by @minrk. Regarding the proposition of Chris, it would require a bit more
> processing on the js side for my usecase, but that would work for me as
> well.
>
> S.
>
> On Wed, Jul 1, 2015 at 4:45 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 1, 2015 at 1: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 the other hand, the hash table is much better for answering the
>> question 'is this id present' than a list. So to some degree, it's a
>> question of which sort of action is more likely based on the reply:
>>
>> 1. check if a particular entry present
>> 2. iterate through all entries, and take some action (list, display,
>> reconnect, etc.)
>>
>> Even if it remains a hash table, the values should probably be dicts, so
>> that there is a place for info about each comm to grow, if we see a need
>> for it.
>>
>> -MinRK
>>
>>
>>>
>>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20150702/f7f8aba4/attachment.html>
More information about the IPython-dev
mailing list