[IPython-dev] Collaborative IPython frontends

[Brian Granger]

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...

Cheers,

Brian

On Mon, Jan 28, 2013 at 8:04 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> 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
> server).
> 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
> 'playback'
> mode for notebook-as-screencast type work (#2832),
> which is a different, and significantly simpler problem relative to live
> collaboration.
>
>>
>>
>> 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
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com