Finalize or remove the notebookControllerKind API Proposal

[mjbvz]

From microsoft/vscode-jupyter#7373

Let's figure out what to do with the notebookControllerKind API proposal. Jupyter is currently the only consumer of it

@rebornix @DonJayamanne Can you please let me know:

• If/how Jupyter is using this API today
• If, in your opinion, this API should finalized or not? Are there any know issues / gaps with it

[rebornix]

I'm leaning towards removing this API though we have seen interest in it. It was introduced to help us group controllers in the kernel picker, but now we are moving towards MRU. It would be a degraded experience if we remove it before having more users using the new MRU kernel picker.

With that said, I'm open to proposals to have it finalized if we find good use of it.

[gjsjohnmurray]

Pinging @davidanthoff because of microsoft/vscode-jupyter#7373 (comment)

@mjbvz your comment that Jupyter is the only current consumer of it may be because it's still only proposed API. Not many extensions get the special privilege of being able to use proposed APIs and be published on Marketplace.

[davidanthoff]

From Julia's point of view, I could see the new MRU experience replacing this. Agreed with @rebornix that the kind property shouldn't be removed until the MRU is finalized and default, otherwise the experience would really not be good.

With the Jupyter extension installed, things look like this to me:

A few comments on that:

• It seems to use the description property to label sources. For example, the Julia extension provided controllers are grouped under Julia Language Support. Would it not make more sense to use the name of the extension there? Or provide the ability to provide a custom string? Julia Language Support there does not seem good to me, but I'm not sure how we could change that.
• Could the Local Kernel Specs... be renamed to Local Jupyter Kernel Specs...? That would make it clear where that entry comes from, namely the Jupyter extension.
• The Local Python Environments... entry seems just a marketing entry for the Python extension. From a Julia user's perspective it always feels strange to be pushed towards that in the UI if one has never indicated any interest in Python in the first place.

[rebornix]

@davidanthoff thanks for your feedback, they make good sense and we have discussed some of the wording, like using "Jupyter Kernel Specs". We will address other feedback in issue #168647

[davidanthoff]

Actually, here is another idea: if the notebookControllerKind property were to be finalized, then we could start to use it with the previous iteration of the UI in the same way that the Jupyter extension is using it right now.

In the new MRU UI, could the notebookControllerKind be the string by which the top level grouping happens? I.e. instead of using the description of the extension, or the name of the extension, could the notebookControllerKind be used if it is set?

That would enable a scenario where things move forward now before the MRU story is finalized, and then there would also be a use-case for the notebookControllerKind in the new MRU UI.

Also, I think this issue here is a dup of #168535, but given that more discussion has happened here, it probably makes sense to close #168535 and continue here.