Open SylvainCorlay opened 8 years ago
For consideration:
completion_request
and inspect_request
?
- Do we still allow other kernel messages such as completion_request and inspect_request?
I imagine that these could be supported aside of the "execute_request" of addressable code.
While I think this model would work very well for parts of the notebook, there are some significant downsides:
Because of these things, I don't think this makes sense for the main Jupyter project to be implemented in this manner. However, I definitely think it may make perfect sense for someone to build a server/client with this architecture for the reason you describe.
There are parts of the notebook UI that do need to send actual kernel messages (tab completion, variable monitoring, etc.). Implementing those would be more difficult as they aren't as stateful.
These shell messages could be exposed by the server and directly forwarded from and to the kernel since they don't change the state of the document or the interpreter.
Because of these things, I don't think this makes sense for the main Jupyter project to be implemented in this manner. However, I definitely think it may make perfect sense for someone to build a server/client with this architecture for the reason you describe.
Although it would greatly simplify live collaboration with widgets. I imagine that we could have the two models coexist.
Hi All,
After a few in-person discussions about this, since feedback has been positive so far (@fperez @ellisonbg @minrk @sccolbert @rgbkrk @Carreau @jasongrout ), I thought that it was a good idea to submit the idea to the list.
What I am proposing here is a significant change in how we deal with the communication between the front-end and the kernel in the case of the notebook which would also apply to contexts such as dashboards.
In my opinion, it would greatly simplify
Let's start with the simpler problem of how to build read-only executable notebooks:
So the proposal to handle this is to forbid the front-end to send
execute_request
messages, and have it send messages to the server of the formexecute cell #af12b239ca3
.The server would have the notebook document model and the content of the corresponding cell.
A user that does not have edit rights on the document model cannot send arbitrary code to the kernel, i.e. it is really a read-only notebook from a security standpoint.
The front-end would not have the ability to modify the code, but only to refer to addressable parts of existing code.
Live collaboration with interactive widgets:
We could go one step further and completely remove the ability of the front-end to send messages to the kernel, including comm messages.
In this case, the interactive widget state would be part of the notebook model held by the server. The only way the front-end interacts with the kernel is by modifying the document model (via widgets or cell content). In the case where a widget model was modified, the server would be the one sending a comm message to the kernel.
I think that it would also simplify the problem of live collaboration with interactive widgets because their would be no way to bypass the server and its conflict resolution by sending directly a message to the kernel.
Conclusion: