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

[Sylvain Corlay]

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/20150701/dce6b8ff/attachment.html>