Provide the server router from a token rather than an app attribute

[fcollonval]

References

Fixes partly #1284. The next step is to make the JupyterFrontEnd more composable to allow dropping the namespacing separation between JupyterLite and JupyterLab/Notebook.

The goal is for third-party developer to be able to hook part of their Jupyter extension into the JupyterLiteServer without additional burden of namespacing plugins (what can be lifted if the Lumino Application is changed to a composition of plugins).

Code changes

Make the server request router available from a token.

User-facing changes

None

Backwards-incompatible changes

None - the router attribute has been marked as deprecated but not removed.

[github-actions]

👈 Try it on ReadTheDocs

[jtpio]

Thanks @fcollonval for looking into this!

The goal is for third-party developer to be able to hook part of their Jupyter extension into the JupyterLiteServer without additional burden of namespacing plugins (what can be lifted if the Lumino Application is changed to a composition of plugins).

Curious if being able to swap the router can already be useful to third-party extensions? Compared to being able to swap the in-browser services (sessions, kernels, contents...), which should already be possible? (just wondering about potential use cases).

[fcollonval]

Curious if being able to swap the router can already be useful to third-party extensions?

You mean accessing the JupyterLite router to extend it, not providing an alternative implementation?

If so, yes it will answer the question. But the challenge that we should lift is the namespacing of plugins. For example, how would you provide the router that is part of JupyterLite server plugins space? Going that road seems more complex and hacky than removing the namespacing following the ability to customize upstream the service manager in the lab application.