-
Notifications
You must be signed in to change notification settings - Fork 301
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
What to do with classic HTML templates #16
Comments
Most should probably go away. 404/error rely on An argument could be made that the pure server doesn't have pages, even errors, and those are provided by extensions, and the default server should have only super-minimal error pages by default. |
We removed most of the templates in #54. We've included a minimal error page and main landing page for the server. The main question I have is, what do we do with templates+handlers for terminals, nbconvert, editor, etc.? The notebook client includes templates, js, and css for these APIs, but the server includes the backend APIs. Should we always require that extensions provide their own frontend to these APIs? |
This might indicate that those APIs should be made into server extensions and remain separate from the server. The server only comes with the pieces in the |
I see that the login/logout templates were removed, but the corresponding handlers are still a part of the server. What is the intended way of operation here? The auth logic should ideally be shared between different Jupyter apps on the same system, so I would argue for keeping some sane minimum implementation. Alternatively, I would prefer to keep at least an extensible template base. |
asyncify provisioner and notebook service
We have kept the HTML templates from the classic notebook server.
I guess that
404.html
anderror.html
and their bases belong to the server. What about the other ones?The text was updated successfully, but these errors were encountered: