multiplex on a 'channel' key in message,
rather than separate websockets.
Unlike zmq, there aren't different message patterns that require the channels to be separate.
Reduces FD count by factor of 3 and connection complexity in js.
And do not require nemaespace either
- this is bad practice, and this prevent from
writing a blended content manager that works both
with drive and localhost as they shoudl both export
themselves to IPython.Contents module.
Updated kernel.js to trigger the ``received_unsolicited_message.Kernel`` event instead. Notebook extensions can handle the event in whatever way they deem appropriate.
A notebook extension that takes advantage of this is available at https://github.com/nheijermans/nbexts.git.
Here's a brief overview of the changes:
- Display of messages from other clients can be toggled on and off from within a notebook, either using the ``<M-m>e`` keyboard shortcut in the web UI, or through the option in the "Kernel" menu.
- notebook.js controls whether messages are displayed through a callback that is invoked from kernel.js when no callbacks are available for a message.
- The UI displays ``execute_input`` messages originating from an other clients in new cells at the end of the notebook. Output messages (``execute_result`` et al.) will only be displayed if a cell exists with a matching message ID.
Pending design questions:
- Should each ``execute_input`` message cause a new cell to be created?
- Should new cells be placed at the end of the notebook, or elsewhere? If the latter, what criteria should be followed?
- various docstrings, comments clarified and updated
- misc typos
- fix and test creating an untitled directory via POST
- only define `message` if there's something to say
Min RK
Bussonnier Matthias
Thomas Kluyver
Nathan Heijermans
Jonathan Frederic
Jason Grout
Scott Sanderson
Jonathan Frederic