Connect to an existing kernel #2044
Comments
Trying to understand the use case, do you mean that the kernel was launched from Fiji and you'd like to connect to it from a notebook in JupyterLab after that? |
Exactly. For example my kernel would return some JSON code to copy/paste in JL (or the opposite). So JL will create a "remote temporary kernel". |
The way this could be done in JupyterLab currently is to start a session using the notebook server from Fiji and then choose that session when creating a new notebook from JupyterLab that is running against the same server. The notebook server itself does not have a way to connect to a remote kernel AFAIK. |
@minrk, do you agree with the above? |
@blink1073 yup. When a kernel is not started by the notebook server, some functionality is missing: interrupt, restart, etc. (this is the difference between KernelManager and KenrelClient on the Python side). However, there isn't really a technical limitation preventing the notebook server from connecting to external kernels. We would just need to handle the "interrupt and restart don't work" behavior in the UI. This gap is precisely what KernelNanny is meant to solve, eliminating the difference in capability between kernels you started and kernels you connect to, making a 'remote' kernel equivalent to a local one. |
Ok thanks for the explanation. But the remote kernel still need this |
For the use case of using a shared kernel on the same server, you would post a REST API request to the notebook server to start the session from Fiji, and then that session would show up in the kernel selection dropdown list in JupyterLab automatically. I'm not sure can reasonably support the use case of connecting to a kernel not started by the notebook server, for the reasons Min gives above. Once we have the kernel nanny, we could make a new REST endpoint that connects to a foreign kernel and then the kernel connection would be the same from the frontend (supporting interrupt and restart). That would leave getting the appropriate connection info for the remote kernel and having a user interface for connecting to a connection file or inputting the kernel JSON directly. As for how to get a connection file, I think it would be up to the kernel to provide that information if it were not started using |
The kernel (based on Beakerx) is added to the kernel list with So, for now, the kernel is started by Jupyter and outside Fiji. I want to keep this behavior in order to make it independent from Fiji. That being said, I would like to adapt that If I understand it correctly The alternative (much simpler) would be to add some UI to JL (or notebook) in order to add a kernel by copy/pasting the What do you think ? |
I am still not understanding. Is the intent to start the kernel from within JupyterLab, get its connection info though the UI, and then input the connection info in Fiji? |
Sorry for not being clear. The Fiji program is juste a zip file that people extract wherever they want in their hard drives and it can also be moved or replaced by another one often. In consequence I don't want to write "in hard" a The sequence I see is :
As an alternative, we can imagine JL displays the connection informations that is then pasted in Fiji to start a kernel. |
We can't support the first option until we have the kernel nanny and changes are made to the server to allow connecting to a remote kernel. |
The second option looks like a good option and should be easy to implement. |
Is that possible or planned to connect to an existing kernel ?
For example, a kernel could return a JSON file with some information for the client to connect such as here http://jupyter-notebook.readthedocs.io/en/latest/examples/Notebook/Connecting%20with%20the%20Qt%20Console.html
Then that would be nice to have a small form in JL to be able to copy/paste the JSON file to create a new "remote kernel".
I am developing a Scijava kernel and I would like users to be able to launch the kernel inside an ImageJ/Fiji instance so it's possible to interact with the ImageJ/Fiji graphical interface directly from the notebook.
See here scijava/scijava-jupyter-kernel#11
The text was updated successfully, but these errors were encountered: