Consider moving `Listener` to `axum-core`

[FalkWoldmann]

• I have looked for existing issues (including closed) about this

Feature Request

Motivation

I am currently working on creating a TlsListener that implements axum's Listener trait (see tmccombs/tls-listener#58). Right now, this trait is defined in the axum crate, which is a little annoying because this means that I need to pull all of axum just for this trait.

Proposal / Alternatives

My idea would be to move this trait to axum-core, but this might not be too easy due to the orphan rule. Alternatively, we could move the impls for TcpListener and UnixListener to axum-core as well and gate it and the additional dependencies behind some feature flag.

[mladedav]

As you said, we'd have to move the implementations, which would make axum-core depend on tokio (possibly behind a feature gate).

I'm not that sure that that's really an improvement.

That said, when you make that library, I assume that the only intended use is for people to create the TlsListener and then pass it into axum::serve. So while you might save some dependencies in your library, any downstream user will have to pull and build all those dependencies anyway so it did not save anyone any time at the end, or am I missing something?

[jplatte]

It could allow that library and axum (and some of its dependencies) to be built in parallel with that library.

I emphasize with this idea of having smaller dependency trees, but I am really uncertain what to do here. Putting it in axum-core has some merit, I guess. But is it an abstraction we will keep as-is for a long time? I did originally like the idea that axum-core would see breaking releases less often than axum, but that hasn't really been the case as much as I thought. Maybe that's fine.

[mladedav]

Right, I didn't think of parallelization of the build.

Another option would be to create axum-serve as a separate library. (With some bike shedding about the name, I don't want to confuse people by having both axum-serve and axum-server even if one isn't in this repo.)

[FalkWoldmann]

One problem of depending on axum is that I would need to enable http1 or http2 feature flag in order to have access to the trait. Perhaps the trait could be moved outside the serve mod?

[jplatte]

Is there anything axum-specific about this? I think having it as a separate tower-tcp-listener crate or w/e could work (assuming tower is the right level of abstraction, it's been a while that I've actually looked at the trait).

[mladedav]

It's axum-specific in that nobody else uses it (yet). But it has nothing to do with Services so I don't think tower is the right level. It also already supports UDS (and who knows, maybe quic one day) so TCP shouldn't probably be mentioned either. It could be something like tokio-listener (that name is already taken) since we need the returned Io to implement traits from tokio.

I think having it just as axum-listener would be fine if we want to allow people to implement it for their types without pulling in too much dependencies (they still need tokio though), I wouldn't expect people to use it for much else. But I might be just short-sighted.