Allow ServerApp sub-class to override webapp handlers about jupyter_server HOT 6 CLOSED

@rolweber could add more insights but a Gateway extension will need similar functionality.

from jupyter_server.

I think there's a bigger conversation to be had here. I explored an approach where the server handlers were configurable, see #29 and #31, added it to an old draft of the Jupyter Server Enhancement proposal, and received negative feedback.

Rather than remove handlers from the core jupyter server in subclasses, I think we need to define: What is the smallest unit that defines a jupyter server? Then, extra handlers (like nbconvert) become server extensions.

This is open for discussion in the Jupyter Server enhancement proposal (though it's received little attention). There's even an issue opened to discuss this point specifically: jupyter/enhancement-proposals#31

I would encourage us to move this conversation over there, as this has big implications on the Jupyter ecosystem...

from jupyter_server.

I think the point of the Voila example is that it needs a Jupyter Server under the covers, but does not want to appear as a Jupyter Server externally, in the network. So even if we define what constitutes a Jupyter Server, a standalone application should still have the option to use jupyter_server through the Python APIs, while disabling the REST APIs for the core functionality.

from jupyter_server.

I made a comment on the JEP issue trying to clarify the discussion. This PR would address what I list as point 2 there.

from jupyter_server.

Cool, I think this proposal makes sense then. Thanks, everyone, for clarifying (especially @vidartf for reviving conversation on the JEP).

I think either "default_services" or "default_handlers" make sense.

from jupyter_server.

Closed by #84

from jupyter_server.