Server should be an executable Future, not an executor (shim) in its own right

[vorot93]

jsonrpc's ServerBuilder accepts a custom executor or starts its own and then requires the user to start it.

On the other hand, both hyper and tarpc build a Server struct that is a plain Future that can be spawned on user's executor of choice. It is way more ergonomic and in line with async ecosystem's move towards separation of logic and its execution.

[tomusdrw]

@vorot93 I agree 100%. Old API is more of a legacy from the times where tokio/futures and async in general was not really a thing yet, we should think on rewriting this if all transports support async.

[christobias]

With a cursory look through the current code, IMHO since ServerHandler is a valid hyper Service, to support this without a breaking API change it would be a good idea to either:

1. Allow taking the ServerHandler from an existing Server, or
2. Split the creation of ServerHandler from Server::serve_http() and provide a way to create Server instances from existing ServerHandlers

The latter option would be a much better fit because users who require just the handler (because they have an existing tokio runtime or hyper instance) can utilize their existing code without extra overhead, while giving a simpler ready-made instance for easier setup

[vorot93]

Actually, this may no longer be a valid issue, given that hyper spawns tasks itself now.

Where I'm contributing (e.g. rust-devp2p) I'm leaning towards such hybrid approach:

impl Server {
    fn new(executor) -> Self
}

impl Future for Server {
    ....
}

Server itself may spawn tasks e.g. to handle each request, while providing a future that resolves when the server is shut down.