❤️ this, since the APIs on the server side have stabilized quite a bit and I think this is generally useful for kernel-gateway, the notebook, and jupyterlab.

/cc @parente

I'd love for kernel gateway to fade away in the long run or at least become an even thinner layer on top of a core jupyter server. So, yea, 👍 from me.

+1 to having just a core server providing the rest api (maybe even that should be a plugin???), and all front ends being extensions on that.

Very much 👍 this. Long time coming.

As hinted at above, there are a number of things currently bundled that might make sense to break out at this time:

• /nbconvert/: move the REST/HTML/PDF/whatever endpoints then move to:
  • jupyter/nbconvert (existing)
  • jupyter/server-nbconvert (probably better)

The other services look like they are pretty much required for basic functioning of getting to a hot websocket pointed at a kernel that you can spin up and down.

The static route is a little troublesome... this seems like something that we could do better on, and if we're going to make breaking changes, perhaps this is the time. Perhaps gently suggesting/forcing per-extension namespacing?

• static/notebook/
• static/lab/

Another thing I'd like more of is declarative/discoverable API description. Perhaps not as far as connexion, but at least giving extension authors a place to put swagger spec (or some other, better spec, if it exists). Enforcing it is a whole other can of worms, but at least being able to hit /api/ and see all the data you could have would be really great.

For the end user, there's a lot of doc/muscle memory out there for <pip/conda> install notebook. Once all this work is done, I assume notebook would then eventually end up being:

• a dependency on syrver (or whatever as per @ccordoba12's comment!)
• a dependency on nbconvert-server (which would enable itself)
• a serverextension
  • a swagger spec
  • a bundle of static files

gently suggesting/forcing per-extension namespacing

👍

I am in favor of this effort. Seems like the main question is this: "do we start to depend on jupyter_server in the classic notebook now or ever." Personally, I am fine doing that for the 5.0 release of the notebook. This is important enough that we may need to discuss it with a larger group of people at our weekly meeting.

Most of the issues in the notebook repos are about the front end, so I am not too worried about migrating the issues.

Regarding the work on the jupyter server, in any case it is probably a good thing to get started early on the server extension mechanism.

I'm on the fence, but currently leaning toward not adding the new server as a dependency for the notebook package, and letting it be a clean fork. Since we are proposing breaking changes and a new extension system there, it seems like it would be painful for both us and users to try to move forward with a new package while using it in notebook that's allegedly in 'maintenance mode'.

Since the current plan means that the notebook package will be entirely obsolete once JupyterLab + jupyter-server are ready, I'm reticent to keep modifying the package until it's gone, rather than leaving it alone.

To me, the main deciding factor is how much more development do we expect to do on the notebook, and there seem to be widely varying views on that point. The only downside to forking jupyter-server instead of adding it as a dependency is that changes/improvements in jupyter-server will not show up in the existing notebook application. I'm not sure that's a bad thing, though, depending on what is planned for those changes.

@jasongrout @blink1073 this to be a good place to add your proposal about how to handle configuration of extension and default url when launching apps.

As requested:

For JupyterLab, we are using the LabApp as an entry point to the server, but do not store LabApp configuration. We separately store LabConfig data in the jupyter_notebook.json file, so we can include the base server configuration as well as the server extension-specific configuration in a single file. In the server extension entry point, we pull the config from the notebook app using nbapp.config.get('LabConfig', {}), so it has been parsed and merged using the same semantics as the NotebookApp config.

cf jupyterlab/jupyterlab#1555

After talking with @SylvainCorlay, I've opened #28 with a new draft of the Jupyter Server EP. Anyone who is interested, feel free to share feedback there. Thanks!

Closing as super-seeded with #28.