Make frontends discoverable and add a frontend alias.

[Zsailer]

One thing that comes up in @echarles server extension example #117 is the ugly syntax for launching multiple frontends (assuming they aren't enabled in the jupyter_server_config.d).
i.e.

jupyter server --ServerApp.jpserver_extensions="{'notebook':True, 'jupyterlab':True, ...}"

I think we should add a --frontend alias

jupyter server --frontend ['notebook', 'jupyterlab',...]

While thinking about this, I also realize we need to be able to distinguish frontends from other server_extensions. Maybe this means we add a frontend property to the ExtensionApp.

Thoughts?

[kevin-bates]

I like both ideas, although I'd like to see the alias be "frontend agnostic" so any server extensions could be listed simply (perhaps named --server-extensions=[]).

If there was a frontend property on ExtensionApp, would that be sufficient to cover both cases (simplified CLI and distinguishing frontends from general server extensions)?

[vidartf]

I also realize we need to be able to distinguish frontends from other server_extensions.

Could you give some use cases for why this distinction is useful? It could help inform whether this is needed or not.

[echarles]

shorter better... --extensions = ['notebook', 'jupyterlab']

But is it agnostic? It seems that jupyter has 99 ways to be extended.

[echarles]

Could you give some use cases for why this distinction is useful? It could help inform whether this is needed or not.

mmh a jupyterlab extension is composed of frontend and optionally of server extensions (in the old term).

I am confused here... Is a classic jupyter sever extension (https://jupyter-notebook.readthedocs.io/en/stable/extending/handlers.html#writing-a-notebook-server-extension) to be considered as the new way to extend this jupyter_server - prolly not... name clash???

[echarles]

Could you give some use cases for why this distinction is useful? It could help inform whether this is needed or not.

A jupyter_server is not always meant to deliver a frontend - It could be a REST endpoint that returns a JSON with e.g. the current authenticated user or the permissions he has. That kind of extensions should not be qualified of frontend

[kevin-bates]

@echarles - I agree shorter is better, but I thought there could be non-server extensions to consider. If that's not the case (sorry, not really up on this aspect of the server), then I agree --extensions would be great.

Things like nbextensions are brought about by other (frontend) extensions - correct? Does server even know about those (or care)?

[Zsailer]

In my mind, there are two classes of server extensions.

1. Frontends—extensions that provide UI for some (sub)set of jupyter_server's REST API
2. non-frontends—extensions that only add extra handlers to the server. They may also include UI for their endpoints, but they don't provide UI for the core jupyter services.

[kevin-bates]

Yes, a "gateway" (Enterprise or Kernel Gateway) is a perfect example of a non-frontend server extension.

[Zsailer]

In my mind, there are two classes of server extensions.

Both can be constructed from the ExtensionApp or load_jupyter_server_extension mechanisms. From the user's point-of-view, non-frontends truly feel like an "extension"; whereas, frontends don't feel like an extension, they just feel like a different mask on the jupyter_server.

Calling notebook, lab, etc. extensions is probably very confusing for users even though, technically, that's what they are. I thought the categorization above is helpful.

[Zsailer]

Things like nbextensions are brought about by other (frontend) extensions - correct? Does server even know about those (or care)?

I don't think so. This should all happen in the jupyter/notebook logic. Server will likely be unaware of this info.

[echarles]

I agree with the above. Still in my mind it is not clear if the old server extensions have to be considered as the new extension mecanism? It is the same name and prolly the same machinery behind, but should we make a distinction for the user/developer?

[Zsailer]

@echarles

Still in my mind it is not clear if the old server extensions have to be considered as the new extension mecanism

I think we keep the server extension mechanism as is. That way, no ones extensions break when they port over the jupyter_server. From a traitlet's perspective, we've renamed them: NotebookApp.server_extensions to ServerApp.jpserver_extensions.

Techically, there is no difference between the two categories above (frontends and non-frontends). In fact, they can add frontends and other server extnesions using the single jpserver_extension trait.

For users, I think it might be helpful to add aliases like --frontends and --extensions. Those aliases would sift through extensions based on the categorization above.

We can also add entry points like:

• jupyter server-frontends list
• jupyter server-extensions list
  to list these items separately.

All of this is just to simplify things for the user. These are problems we didn't have in jupyter/notebook because a default frontend came with the server.

[echarles]

Via which config would an extension be qualified of server-frontends or server-extensions. I don't see a way to define such attributes in a json such as

{
    "ServerApp": {
        "jpserver_extensions": {
            "notebook": true
        }
    }
}

We should go with a more nested structure like

{
    "ServerApp": {
        "jpserver_extensions": {
           "frontends": {
             "notebook": true
           },
           "services": {
             "simple_ext1": true
           }
        }
    }
}

PS: Maybe frontends or services is better than frontends or extensions.

[echarles]

@Zsailer @kevin-bates Percolating more on this, an extension can have UI (user interface) or not. It would be the server responsibility to say if it has a ui/frontend or not based on the template_path and static_path. If one of those 2 guys is set, then the extension has a UI/Frontend.

For jupyter server --ext lab,voila,user_api, we would have

jupyter server extension list

lab (ui)
voila (ui)
user_api (no ui)

We can also nest more attributes like description and picto that would be used in an admin ui.

{
    "ServerApp": {
        "jpserver_extensions": {
             "notebook": {
                "enabled": true,
                "description": "The famous Jupyter Notebook",
                "picto_uri" : "static/picto.png",
        }
    }
}

mmh I realize now that we would need in anyway to ship a picto image in a static folder, so we would need to have a static_path even if we don't have UI. The other way would be to explicitly add a attributed ui: true/false. Then

jupyter server extension list

notebook (ui:true) The famous Jupyter Notebook

[echarles]

Those attributes could be used by the operator to override the extension attributes defined by the developer.

[echarles]

FYI vscode had similar thoughts/questioning. They committed 2 days ago extension kind ui to be ui + workspace. You can read more microsoft/vscode#85036.

So they have some ui or workspace extensions. The extensionKind is now an array.