[IPython-dev] IPEP 3: Multiuser support in the notebook
bussonniermatthias at gmail.com
Sat Sep 8 05:02:50 EDT 2012
Comment on current IPEP version :
> • Users will have the ability to "live share" notebooks and their kernels. When a user clicks "live share" they will get a private and secure URL they can share with other users. These other users can then edit the notebook and run code on the kernel in a Google Docs like manner.
This is one feature, but I would expect the ability to invite/remove user independently.
Either by being able to tick checkboxes, or else. But nothing annoy me more than having to look into my email to find the link.
Ability to have "soft" more grained privileges. Invite a user than can only edit and not run.
Obviously we are really vulnerable to JS injection. We should definitely try to do something about that, even if we sell the notebook as beeing not totally secured. One thing we can use is html5 sandboxed feature of iframe. This could also solve the "problem" of css in ".rendered_html".
Implementation wide for live collaborating, we should redirect the message using cell ID, otherwise this is a huge problem to redirect IOPub to all clients.
> • Version control of notebooks will be done using the command line interface to git and other VCSs. These VCS command will be issued through the shell widget.
I think some high level command would be great, like changing 'save' button, to 'commit' with a custom message that can be generated by user.
One of the things I came across while prototyping live collaboration is the real need to have the current state of the notebook on the kernel side.
I think we should define a format of notebook 'patches' that represent common operation on a ipynb file, at least:
- appending/moving/deletting worksheet/cells
preferably with reference to the worksheet/cell by UUID.
I also think that for live collaboration we need both a 'cell is being edited' lock, and also maybe a 'cell is being executed' lock.
shift+Enter in collaboration is annoying as it makes you select the next cell, releasing your lock and selecting a new cell, potentially locked.
I would be inclined to change ctrl+enter to execute without selecting all to be able to stay on the same cell.
Le 8 sept. 2012 à 01:19, Fernando Perez a écrit :
> On Fri, Sep 7, 2012 at 3:50 PM, Jason Grout <jason-sage at creativetrax.com> wrote:
>> Are you saying that the two of us will be interacting with one running
>> kernel? Or are you saying that we both have different kernels and the
>> outputs are somehow pushed back and forth between our representations?
>> The former seems more likely, but I was just checking. In Sage we have
>> the latter (IIRC), and sometimes it gets really confusing.
> The former. We envision collaboration similar to Gdocs, running
> against the same kernel, but with cell-level granularity for
> concurrent typing instead of character-level. When a user starts
> typing in a cell, the others would see it shaded with that user's
> name, effectively locking cells, so that they don't trample on each
> Creating a framework for synchronizing at the cell level is easier and
> less finicky than getting something like google docs that syncs
> character-by-character. And I also don't quite like the feel of
> complete 'all hands at the same time' editing gdocs provides, so
> hopefully this will be a good experience. We'll have to see.
> IPython-dev mailing list
> IPython-dev at scipy.org
More information about the IPython-dev