[IPython-dev] Collaborative IPython frontends
Mon Jan 28 22:14:46 CST 2013
Min has made most of the points already but just to agree with him:
* Much of the notebook/kernel architecture is already "collaboration enabled"
* This is pretty high on our priority.
* It will be a significant amount of work = rewriting much of the
server+client side notebook.
* We are just not there yet and because of other work going on right
now we are not ready to tackle this yet. It is not a question of
manpower, it is a question of focus for the project.
* Please be patient with us in the meantime...
On Mon, Jan 28, 2013 at 8:04 PM, MinRK <firstname.lastname@example.org> wrote:
> On Mon, Jan 28, 2013 at 6:02 PM, W. Trevor King <email@example.com> 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/terminal/console/app.py, and
>> IPython/frontend/qt/console/qtconsoleapp.py frontends, as far as I can
>> 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.
> mode for notebook-as-screencast type work (#2832),
> which is a different, and significantly simpler problem relative to live
>> 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 mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
firstname.lastname@example.org and email@example.com
More information about the IPython-dev