“Jupyter Server” is Jupyter Notebook without a front end bundled in its installation. That is, it does not include a “client” web application and is merely a web server. Jupyter Lab, and its various extensions, utilize the REST API exposed by Jupyter Server. “Jupyter Server” is more than kernel management, in that it also provides content services for maintaining notebook files within a directory structure and exposes a Session manager through which most interactions occur.
“Gateway Servers” (Kernel or Enterprise) only expose the “kernel management” REST APIs. So, in that sense, they are considered a “kernel management” tool. They do not provide content services.
The missing piece now (I think) is that I don’t see how to actually get the connection info for a kernel that is managed by JKG, which would still be necessary in order to actually connect the client to the kernels managed by JKG. I didn’t see any mention of this specifically in the JKG docs.
A kernel’s connection information is maintained by the “launching server”. So, in the case of a gateway configuration, where the gateway is remote from Jupyter Server, the connection information is not directly available to Jupyter Server. However, in this case, Jupyter Server’s KernelManager is configured to proxy requests and gather results to/from the Gateway, thereby allowing the various client applications of Juptyer Server to use remote kernels.
In what sense is the kernel’s connection information “necessary in order to actually connect the client to the kernels managed by JKG”? Are you referring to client applications that are not browser-based? Can you provide concrete examples of such applications?