Open a new notebook while connecting to an existing kernel (opened by qtconsole or terminal or standalone) #1220
Conversation
…ing the kernel in the file. This allows us to start a new notebook with existing kernels. Moreover if we supply the connection file details of a qtconsole based kernel or a terminal based kernel or any standalone existing kernel files, we can connect the notebook to it.
…existing kernel files.
We do this so that when the kernel file name is supplied as part of the URLPattern we can open a new notebook based on the kernel information supplied in the file that already exists.
|
There is a huge amount of complexity lurking in this direction that we don't want to get into at this point. It was a deliberate choice to stick with the 1 notebook = 1 kernel constraint for now. To go this direction we would need to completely rethink how kernels and notebooks are related and develop a UI for linking arbitrary notebooks to arbitrary kernels. It would also require a complete reworking of the server backend. There are a number of other more pressing things on the table for the notebook right now so I don't think it makes sense to pursue this right now. But even more important is that we are aiming to keep the notebook as simple as possible and that would introduce a huge amount of complexity that many users will find confusing. It is an additional level of abstraction that requires user to keep track the various kernel namespaces in their head. One feature we do plan on implementing that would provide some of the same user experience without the confusing aspects is having multiple "worksheets" in a single notebook. This would basically provide tabs in the notebook where all tabs point to the same kernels. This would allow users to organize their notebook into logical sections, but maintain the 1 kernel = 1 notebook constraint. |
|
Oh Ok. I honestly do not know the complexities involved since I do not have the full picture. If that is the reason why this doesn't exist, it makes sense. Just one question about the feature of multiple worksheets. Will that work across machines? |
|
On Tue, Jan 3, 2012 at 11:36 AM, Madhusudan.C.S
Not quite sure what you mean by across machines. Could you clarify that?
Brian E. Granger |
|
Will it be possible to open a different worksheet on a different computer? |
|
Brian, I haven't read the code yet so I'm not sure of all the details, but my understanding from Madhu's description was not that it changed the 1-1 mapping of notebooks to kernels, but rather that it enabled notebooks to be hooked to already running kernels. That's precisely what the qt console and console both do with the Now, the only thing I'm talking about is what kernel a notebook is opened against when freshly opened. For example, once a notebook server has associated a notebook file with a kernel, it should not be possible to reopen the same file with a different kernel (to avoid the confusion Brian alludes to). But at first shot, when no kernel has been created yet, it should definitely be possible to say 'open this notebook file -- or make a new one-- against this existing kernel' just like the |
|
You are right that it primarily addresses the usage case of an existing kernel that was started outside the notebook. But I think this still does break the 1-1 mapping. By that, I mean that the change would allow a single notebook to be hooked up to a number of different kernels. It doesn't matter that those other kernels were started outside the notebook. It becomes a 1-N mapping, although the notebook is hooked up to a single kernel at one time (not sure how a notebook could be hooked up to multiple kernels simultaneously). Implementing this in the right way would involve changing the URL scheme in significant ways and introducing new abstractions in the server side code for linking kernels to notebooks. We are about to embark on a radical refactoring of the URL scheme and I don't want to introduce new things in a semi-thought-out way at this point. The refactoring process would give us a chance to consider how these things could be handled properly. While I see the usage case for hooking a notebook up to existing kernels there is a significant complexity cost in going down this path that we can't ignore. It forces the user into thinking abstractly about notebooks and kernels in a manner that is quite subtle. And it does so the second the user tries to open a new notebook. For us, the abstraction of the kernel and frontend is completely natural. But we have been thinking about this for years and most python users, even relatively advanced ones, don't think in these terms. I would almost (not quite though) say that the kernel abstraction is an implementation detail that new users should never need to worry about. If we ever go down this path (I am still not convinced), we would need to design a UI that completely hides these things from new users and only exposes them to advanced users when they ask for it. I feel strongly that the notebook needs to have a UI that inexperienced users can use with 0 documentation. It needs to be as simple as angry birds for these users. Think of a freshman in college with no programming experience for whom the statement "a=10" involves a significant cognitive load. The (fun!) challenge for us is that we also want the notebook to be a powerful almost-IDE environment for the best and brightest programmers in the world. |
|
This will be continued in #1274. |
This adds a new GET handler for the /kernels/<kernel_id> RequestHandler which opens the new notebook based on the kernel file name specified as the value for the kernel_id argument in the URL.
On the UI side, it looks like this. The main dashboard already has a New button. Upon clicking it, a dialog opens with a text box with the label "kernel". It is not a mandatory field. One can leave it blank in which case it opens up a new notebook with new kernel and it is the same as the action that happens when we click the new button as of now. But if we choose to put the name of the kernel file, say "kernel-5151.json", it redirects to the URL /kernels/kernel-5151.json and opens a new notebook with that kernel.
This is not a perfect patch. I do not even expect this to be merged right away. It needs a lot of changes. So it is a first cut. Sending a pull request just to draw some attention for discussion.