[IPython-dev] IPEP 3: Multiuser support in the notebook

[Brian Granger]

Matthias,


On Sat, Sep 8, 2012 at 2:02 AM, Matthias BUSSONNIER
<bussonniermatthias at gmail.com> wrote:
>
>
> 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.

One thing we need to think through is the different "modes" a user can
view a page in.  Minimally we have three boolean flags that determine
the mode: read, write, execute.  Are there others?

One big thing we will have to work out is how to tune the
content/display of each page in a way that reflects these flags, but
that is secure.  Our current approach of setting a variable in JS to
control things is horribly insecure.  Ideas on this?

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

I agree we need to think more about security, but that is really off
topic for this IPEP (i.e., the same technical problems exist for the
single user notebook).

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

I am not quite following you here.  Don't all clients need to get all
iopub messages?

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

We have talked about this before and we want to avoid creating a git
UI in the notebook.  The other issue is that repo level actions are
not per notebook, but per directory, so if we did add a commit button,
it would need to be on the directory dashboard, not the notebook page.

> 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 am not sure what you mean by having the notebook state on the
kernel.  We have to be very careful to keep the notebook and kernel
state completely separate.  Can you elaborate on why this was needed?
But actually, can you open a separate IPEP for live collaboration - it
is really a big topic in itself.

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

Yep, I think at the cell level that having locks like this makes sense
for us.  The problem is doing so in an asynchronous setting (what if
both of us lock the same cell before the server is notified?)

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

Yes, we will have to think carefully about what the cursor does upon
executing a cell in live collaboration.

> --
> Matthias
>
>
> 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
>> other.
>>
>> 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.
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> 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