RFC: Integrate IKernelProvider into codebase

[captainsafia]

Inspired by the work @gitanuj and @languy have brought over to the repo with the concent of the IContentProvider, I'd like to introduce the concept of an IKernelProvider. This RFC outlines the problem and why I believe that IKernelProvider is the right solution to implement.

Problem Currently, code for handling fundamental interactions with the kernel (like interrupt and restart) is distributed across different epics within @nteract/epics and the nteract desktop app. Furthermore, the API interface across the two epics is inconsistent. For example, a different error message text might be returned from each epic or one epic might handle some errors that the other doesn't.

Finally, there is a lot of differences between the ways that 0mq-backed kernels and WebSocket-backed kernels handle their statuses. A unified IKernelProvider interface would clean up the amount of

Solution Since all kernels have the same fundamental interactions, we need an abstraction layer over these interactions so that we don't have to implement too much duplicative logic and so that the interface for both actions is the same across nteract desktop and web clients.

I propose that we implement an IKernelProvider interface, which can be injected as a dependency into the epic middleware, in the same fashion as the IContentProvider.

Implementation

The IKernelProvider should have the following interface:

interface IKernelProvider {
    interrupt: (kernelRef) => InterruptKernelActions;
    shutdown: (kernelRef) => ShutdownKernelActions;
    start: (kernelRef?) => StartKernelActions; // And creates the KernelRecord
    restart: (kernelRef) => RestartKernelActions;
    get: (kernelRef) => FetchKernelActions;
    list: (hostRef) => ListKernelActions;
}

In implementing this IKernelProvider model, we will have to migrate our current 0mq and Websocket-based kernels to this model.

0mq-based kernels will build on top of enchannel-zmq-backend for all their interactions.

WebSocket-based kernels will use the sessions API for all interactions listed above (except interrupt and restart).

Questions

• Did I miss any necessary kernel actions in the interface above?
• Are there any noticeable differences between 0mq and Websocket-based kernels that would make this abstraction difficult to implement.
• Thoughts overall?

cc: @languy @gitanuj @rgbkrk

[rgbkrk]

I think the only extra difficulty is that websockets have fairly different reconnection and error logic from the zeromq sockets. That can probably be abstracted within here though.

[gitanuj]

I'm not familiar with zeromq based kernels but your interface covers all the operations supported by Jupyter kernels api. Looks like a great change to give Nteract apps flexibility to how they host kernels.

[willingc]

@captainsafia In trying to fix autocomplete for Julia, I've spent a fair amount of time starting and restarting the iJulia kernel. The slow response and error messages (re: shutdown of old kernel) when the new kernel is up is problematic. There are a number of timeouts in the kernel handling that I believe are causing a bunch of the latency on restart/start.

This seems like a reasonable approach to me.

[languy]

nit: beside start and possible get, shouldn't all the other api's require a kernelRef? I wonder if this interface can be abstracted at a lower level so that it doesn't require redux and its method return some rxjs observable like the IContentProvider does.

[captainsafia]

@languy Sure! That makes sense and would enable using this interface in situations where there is no content (for example, on play.nteract.io). I'll update the original comment above.

[stale[bot]]

This issue hasn't had any activity on it in the last 90 days. Unfortunately we don't get around to dealing with every issue that is opened. Instead of leaving issues open we're seeking to be transparent by closing issues that aren't being prioritized. If no other activity happens on this issue in one week, it will be closed. It's more than likely that just by me posting about this, the maintainers will take a closer look at these long forgotten issues to help evaluate what to do next. If you would like to see this issue get prioritized over others, there are multiple avenues 🗓:

• Ask how you can help with this issue 👩🏿‍💻👨🏻‍💻
• Help solve other issues the team is currently working on 👨🏾‍💻👩🏼‍💻
• Donate to nteract so we can support developers to work on these features and bugs more regularly 💰🕐

Thank you!