[IPython-dev] IPEP 3: Multiuser support in the notebook
Sun Sep 9 15:13:50 CDT 2012
On Sun, Sep 9, 2012 at 12:36 PM, Matthias BUSSONNIER
>> > 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).
>> If you don't allow collaboration, then yes this is off topic.
>> As soon as you add collaboration with username and password, you have a risk of user stealing each other account.
>> We should think of it while building multi user account.
>> Collaboration is hugely complex, and I think it warrants an entirely separate discussion.
>> >> 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?
>> Yes they do.
>> But they don't now how to handle it.
>> if I run Safari and Chrome on "notebook_a"
>> When I execute "1+1" on Safari, for cell 54, when iopub arrives on Chrome, it has no idea of what to do with it.
>> I think we should proxy :
>> Browser(s) ===>===> [execute+cell_id(+uuid ?)] ===>==> server strip cell_id (, add uuid) ? ==>==> kernel
>> Browser(s) <===<==<===<===<===<==<===<===<=== server match uuid, append cell_id <==<=== kernel
>> I don't think we want to do this.
> The problem I came across then she doing live collaboration, is others browsers not knowing for which cell iopub is meant.
> * Browser send execution request,
> * IOPub and answer came back.
> * current cell/output to json, tagged with cell id.
> * send to the server, that redispatch to other Clients browser.
> I thought this was inefficient, especially depending on how you want syncing to be fine grained, you had to resend at "every" received iopub messages.
OK I am following you now and agree that this is not very efficient.
There is also the issue of how to handle long running cells where a
user closes the notebook and then the result returns over iopub.
Currently any output that is not loaded into an open notebook is lost.
We do need something on the server side that *always* has the full
state of the notebook document. My thought for this is that the part
of the server that handles live collaboration and saves, should
subscribe to iopub should put the data into the notebook document and
then broadcast it to clients. If we move in that direction, the
notebook would no longer monitor iopub directly, but would instead
monitor diffs coming from the server. But again, these are huge
issues that we need to discuss in a IPEP on the topics.
I think we will have to learn about Operational Transforms (used by
Google Docs and Wave). ShareJS is an interesting start:
> IPython-dev mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
email@example.com and firstname.lastname@example.org
More information about the IPython-dev