How *should* other applications interface with jupyter server?

[Zsailer]

Pinging @SylvainCorlay, @blink1073 and @jasongrout.

I'm hoping this discussion will bring me up to speed on everyone's thoughts/plans, so I apologize for anything that I say that's naive 😆

Essentially, I'm asking how should applications like the class Notebook, jupyterlab, etc. interface with the server? (I realize there's a big discussion that needs to happen about how we handle configuration, especially in a backward-compatible way. For now, I'm ignoring that question and just asking what is the end goal for jupyter_server).

1. Everything is a server extension

One approach is that each application is loaded through the server extension logic.

def load_jupyter_server_extension(server_app): 
    # 1. Pass application settings to Jupyter WebApp (this requires new logic)
    # 2. Add handlers to Jupyter WebApp

Each extension is added to the server extension list in the server config. The server has one entry point jupyter server (though we'd need to add shims for backward compatibility). The server+webapp launch and load the server extensions (i.e. the classic notebook, lab, etc.). Each extension loads it's specific configuration and these additional settings are added after the server and webapp are created. I'm not sure how we'd handle extension configurations from the CLI (will likely new traitlets logic...).

In this scenario, the jupyter ServerApp and WebApp are a general applications that expose API's to the backend jupyter services. Jupyter lab and the notebook are (first class) external applications that interface with server. As an example, here is a branch of the classic notebook that uses the current server extension logic to load the notebook.

2. External apps subclass the server+webapp

Every external application subclass the jupyter ServerApp and WebApp and add/update application specific configurations to these classes (I think this is what jupyterlab_server does?).

In this case, each application comes with their own server, webapp, configuration template, and entry-point.

[blink1073]

My inclination is that we'd follow the model used by JupyterLab for all server applications (which are a subset of server extensions): they can function either as Application or purely as an extension. We can probably step back and rethink how this was done in jlab and how it would apply to NotebookApp as well.

[kevin-bates]

@Zsailer Thank you for opening this discussion!

Although I'm not one of the targeted responders, I would like to add my two cents (primarily because I have a vested interest in how this proceeds). I'm not familiar with server extensions outside of NB2KG. This extension essentially configures various classes that override kernel management and proxies the kernel management to a remote Kernel Gateway. This enables the ability to separate notebooks from kernels and, with Enterprise Gateway, the ability to have those kernels launched across managed clusters. I'm not sure if this extension would be considered an example of a "server extension" in the new jupyter_server sense.

However, applications like Enterprise Gateway (and Kernel Gateway upon which EG itself is built), could only have achieved the functionality they provide by subclassing various pieces of the "server". These are true server-side applications that fundamentally change the "behavior" of that particular server instance by essentially creating a Kernel As A Service model while supporting a large set of options pertaining to the functionality they provide. As a result, I suspect you'd actually want a different application in this case, but one built on the core framework that is jupyter_server.

I suppose one could always spin any kind of functionality in terms of "extensions", but I'm hoping that jupyter_server continues to provide the ability to alter the class hierarchy in order to maximize extensibility.

I'd love to help out wherever possible on this project especially in the area of kernel management.

[Zsailer]

Hi @kevin-bates Thanks for joining the conversation! This was helpful.

I agree with @kevin-bates and @blink1073. Subclassing the ServerApp makes the most sense, specifically, for projects that change the server behavior. It also helps with code maintenance on sub-projects, configuration sanity, etc.

I am thinking we should make the ServerApp and ServerWebApplication general classes that load custom services, as well as server extensions. This would mean, we add a services trait in the ServerApp that lists the services available in the corresponding web app (much like the server extension list). Currently, the ServerApp (and the classic notebook app) automatically loads a bunch of server-side services (i.e. kernels, terminals, signals, nbconvert, etc.) that applications like Enterprise Gateway have to remove/change. We can add logic that allows projects like EG to just change the services trait and the ServerApp's methods know how to process everything downstream.

Practically, I think this means:

1. Defining a template+documentation for writing custom handler+manager submodules for a custom service.
2. Adding logic to ServerApp that finds such handlers+managers.
3. Adding logic to properly handle configurations for handlers.
4. Adding logic to init handlers in ServerWebApplication and pass managers to tornado settings attribute in the web app
5. Making the ServerApp's initialize method only load services listed in the services trait.

[Zsailer]

For reference, here is a list of projects that that might benefit from this split:

• kernel_gateway
• enterprise_gateway
• ipywidgets_server
• jupyter_kernel_mgmt

[kevin-bates]

Although at a lower level, @takluyver's jupyter_kernel_mgmt (see PR 4170) should probably be taken into consideration. Since there appears to be building momentum for changes in the server-side kernel and kernelspec management arena, I'm wondering if this wouldn't be a good topic for a community workshop or some set of meetings so we can all get on the same page. If others agree, I would love to participate and represent the gateways.

[Zsailer]

Added jupyter_kernel_mgmt to the list! Thanks!

[Zsailer]

@kevin-bates I'm not sure if there enough people to pull together for a community meet-up. We'd need 12-24 people. Do you have specific people in mind?

[kevin-bates]

I see - I didn't realize the workshops were that large.

I'd like to make sure we're on the same page for future direction to avoid sibling projects like the gateways from getting orphaned because the new approaches didn't take them into consideration. I'm relatively new to Jupyter (and Open Source in general), so I'm not sure how to "keep tabs" or proactively contribute - other than watching dozens of repos, monitoring the forums, and filtering on items of interest (in particular, the future direction of kernel management).

[ivanov]

Hi both! I just wanted to pop in and encourage you both to submit a community workshop application. You don't need to have all of your attendees figured out ahead of time, and you can get up to a dozen folks in most geographical locations fairly quickly.

[Zsailer]

Thanks, @ivanov! Okay, you convinced me ;) I'm up for it.

How about you @kevin-bates? Would you be interested in co-organizing a meetup together?

[kevin-bates]

@Zsailer - just to make sure. Are you referring to a workshop, per the blog I referenced previously, or a single-day meetup? I'm assuming the former.

One of my colleagues on EG - Luciano (@lresende) - has volunteered to help out with organization of a workshop although I'm happy to help out in other capacities. I'm hoping we can make this happen.

Thank you @Zsailer and @lresende!

[Zsailer]

@kevin-bates - yes, I was referring to the 2-3 day workshops described in the blog (funded by Bloomberg). Thank you for suggesting the idea!

Hello @lresende! Thank you for volunteering to help organize a meetup. I think the first thing to do is submit a proposal to the Jupyter steering council. Do you have time today/tomorrow for a video call to discuss details?

[lresende]

@Zsailer I am available to chat today or tomorrow (pst timezone), I am also working on a draft proposal based on the blog link. Let me reach out to you via e-mail to schedule something

[Zsailer]

I am also working on a draft proposal based on the blog link. Let me reach out to you via e-mail to schedule something

Oh, fantastic! Thank you for heading this. I look forward to chatting this afternoon.

[Zsailer]

Closing this issue. We just finished a Jupyter Server Workshop!

We'll be sharing a bunch of updates from this workshop very soon.