Proposal: JDK-only server implementation (repurposed OkHttp Server)

[bsideup]

Is your feature request related to a problem?

Currently, there is no "zerodep" transport that uses JDK types only

Describe the solution you'd like

Repurpose OkHttpServer that does not in fact depend on OkHttp (only Okio but even that dependency can be removed) as a generic JDK-only server implementation.

Describe alternatives you've considered

Existing servers work fine but sometimes cause version conflicts. Also, Netty remains the reference server, and, while being performant, its implementation is harder to follow due to the async nature and Netty's way of doing things.

Additional context

I am working on https://github.com/bsideup/grpc-bidi ("push" for gRPC, a.k.a. client-side channels) and it needs to expose itself as a server, with ClientCall being the transport. Currently, it uses the Netty server impl, but it is rather complex, plus requires a heavyweight dependency.

[ejona86]

What version conflict is there with grpc-okhttp? Sounds like you want something small, and that is what grpc-okhttp is intended for. You would need to make a much stronger case for a new transport implementation. (I don't really see any real argument here; I just see an assertion.)