[IPython-dev] Collaborative IPython frontends

MinRK benjaminrk at gmail.com
Mon Jan 28 23:04:27 EST 2013

On Mon, Jan 28, 2013 at 6:02 PM, W. Trevor King <wking at tremily.us> wrote:

> I've been browsing through the docs and source off and on over the
> past few days trying to get a handle on a collaborative IPython
> workflow.  There's a “collaborative scenarios” hint in
> docs/source/development/messaging.txt and talk of an --existing option
> in docs/source/interactive/qtconsole.txt.  It looks like the support
> for the connect_info magic lives in IPython/zmq/zmqshell.py, but
> support for --existing seems spotty (it's only supported by the
> IPython/frontend/consoleapp.py,
> IPython/frontend/terminal/console/app.py, and
> IPython/frontend/qt/console/qtconsoleapp.py frontends, as far as I can
> tell).
> Is this still a work in progress?  Is some sort of collaborative
> session sharing in the pipes?  It looks like the kernel only handles
> Python command execution (without notebook extensions like input cells
> and Markdown rendering), so the collaborative use would only be
> sharing a central, kernel-bound Python context.

Real collaborative integration is absolutely in the works for the notebook.
This will require a significant change to how the notebook handles saving
and document state, but it is one of our highest priorities.

Note that notebook session sharing and kernel sharing are two related, but
not identical things.
Sharing a notebook means sharing the entire document state (cells, etc.).
Sharing a kernel *only* means sharing execution state - this is what we
already have today in all contexts (including the notebook with the caveat
that notebooks cannot connect to kernels started outside the notebook
The kernel is never going to get document state.

We do not have any plans to have synchronous sessions
including input and output in the terminal or qtconsole,
though the only missing piece is actually the UI - 100% of the
technical considerations are already done,
as input and output are broadcast to peer frontends.
Currently, however, those messages are discarded by the peers,
but they could just as easily be displayed.

> My end-goal is to get some sort of recording and playback for
> notebooks at the cell-action level (e.g. Markdown cell rendering,
> Python cell execution, …), and it seemed like a logging “frontend”
> could be attached as a collaborator to an existing notebook
> frontend/kernel.  Then the log could be played back using a playback
> “frontend” and viewed in a collaborating notebook.

This is our goal as well.  We are currently working on a Javascript
mode for notebook-as-screencast type work
which is a different, and significantly simpler problem relative to live

> Thanks,
> Trevor
> --
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
> _______________________________________________
> 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/20130128/4eecef3d/attachment.html>

More information about the IPython-dev mailing list