Description
During jupyter-server meeting we discussed the possibility of enabling the frontends to ask for and receive the content from the kernel. This is distinct from the current contents manager APIs in jupyter-server which gets and puts content in the jupyter server root.
For context, this sprout out of a discussion on file ownership/path resolution endpoint proposed for jupyter server, with motivating use case for the frontend to decide which API to hit to get a source file when user clicks on a file name to open the file (e.g. in a traceback):
- Resolve server absolute path to server or kernel-relative path jupyter-server/jupyter_server#1280
- Path resolver API jupyter-server/jupyter_server#1331
- Path resolution by kernel manager and providers #1005
There were two concerns raised for the above proposal:
- it adds a new REST API addressing only one very specific use case
- there is interest in exposing much more of the kernel contents to the frontend
- it would require gateway to implement another step to pass the resolved path if that was to be accepted
Previously, another proposal was raised on sidelines of jupyter-server team conversation, involving exposing kernel contents via comms. In that proposal a ContentManager
-like API would be optionally implemented by the kernel and available to the client by comms. This was proposed for ipylab by @bollwyvl:
It is not clear to me how this should be implemented, both on code level nor on architectural level, so I would greatly appreciate more thoughts on how it could/should function. CC @Zsailer.