<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 1, 2015 at 3:35 PM, Chris Colbert <span dir="ltr"><<a href="mailto:sccolbert@gmail.com" target="_blank">sccolbert@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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:</div><div><br></div><div><font face="monospace, monospace">`{ type: 'comm_info_reply', comms: [ { id: 'foo', target: 'ipython.widget' }, ... ] }` </font></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Jun 27, 2015 at 11:46 PM, Sylvain Corlay <span dir="ltr"><<a href="mailto:sylvain.corlay@gmail.com" target="_blank">sylvain.corlay@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi All, <div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><p dir="ltr">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.</p><p dir="ltr">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</p><p dir="ltr"><b>jupyter-client:</b> <a href="https://github.com/jupyter/jupyter_client/pull/34" target="_blank">https://github.com/jupyter/jupyter_client/pull/34</a><br></p><p dir="ltr"><b>ipykernel:</b> <a href="https://github.com/ipython/ipykernel/pull/25" target="_blank">https://github.com/ipython/ipykernel/pull/25</a>    (requires the previous PR)<br></p><p dir="ltr"><b>notebook:</b> <a href="https://github.com/jupyter/notebook/pull/166" target="_blank">https://github.com/jupyter/notebook/pull/166</a>   (requires the two previous PRs)<br></p><p dir="ltr"><b>ipywidgets:</b> <a href="https://github.com/ipython/ipywidgets/pull/62" target="_blank">https://github.com/ipython/ipywidgets/pull/62</a> (requires the three previous PRs)</p><p>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 <b>comm_info_[request/reply]</b>. The reply message a dictionary containing one key, called `comms`, which itself contains a dictionary of the form `<b>{comm_id : target_name}</b>`</p><p>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 <b>comm_info_reply</b> message in the future.</p><p>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!</p><p>Thanks,</p><p>Sylvain</p></div></div>
<br></div></div>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Kyle Kelley (<a href="https://twitter.com/rgbkrk" target="_blank">@rgbkrk</a>; <a href="http://lambdaops.com/" style="color:rgb(17,85,204)" target="_blank">lambdaops.com</a>, <a href="http://developer.rackspace.com" style="font-size:12.8000001907349px" target="_blank">developer.rackspace.com</a>)</div></div></div></div>
</div>