Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ServerApp sub-class to override webapp handlers #80

Closed
vidartf opened this issue Aug 21, 2019 · 6 comments
Closed

Allow ServerApp sub-class to override webapp handlers #80

vidartf opened this issue Aug 21, 2019 · 6 comments

Comments

@vidartf
Copy link
Member

vidartf commented Aug 21, 2019

Given e.g. the case of Voilà, you want the server to not add some of the default handlers (while you want some of them). This should ideally be overridable by a subclass of ServerApp (but probably not user configurable?).

Taking the Voilà example again, you probably want to:

  • Keep the configurable login/logout handlers.
  • Keep the kernel/kernelspecs/security handlers.
  • Not keep the contents/file/view/edit/nbconvert handlers.
  • Modify/customize/restrict the shutdown/sessions/config handlers (?).

These are all currently hard-coded in the web-app. I'm not sure what the best way to configure these would be, but the pattern from extra_services seems like a good one (maybe default_services?).

@kevin-bates
Copy link
Member

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

@Zsailer
Copy link
Member

Zsailer commented Aug 21, 2019

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...

@rolweber
Copy link
Contributor

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.

@vidartf
Copy link
Member Author

vidartf commented Aug 23, 2019

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

@Zsailer
Copy link
Member

Zsailer commented Sep 9, 2019

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.

@vidartf
Copy link
Member Author

vidartf commented Sep 13, 2019

Closed by #84

@vidartf vidartf closed this as completed Sep 13, 2019
Zsailer pushed a commit to Zsailer/jupyter_server that referenced this issue Nov 18, 2022
* include version file

* lint

* cleanup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants