NIOAsyncChannel HTTP1 Server Setup

[taylorswift]

@Helge_Hess1

Yes, but my complaint about extras here is that it is not fractured enough Things like NFS should really be own packages. (it is a style/taste question, e.g.

but this makes the libraries much harder to test, because each component has an independently-incrementing version series. it will never be possible to test enough of the (exponential) combinations of versions people could be using, so you end up with a lot of it works on my machine ¯_(ツ)_/¯.

there is not going to be any overhead associated with the unused targets in a package dependency in the compiled binaries, so it just doesn’t seem to be a worthy tradeoff in my opinion.

@Helge_Hess1

I also dislike having all the examples in the core NIO repo, that IMO just spams the package

i can think of at least two things NIO could do to alleviate this problem:

1. NIO could move the examples to a nested swift package in the same repo, like it is already doing for its benchmarks.

2. NIO could convert some of the simpler examples into SPM Snippets, which were designed for exactly this situation and would go a long way towards reducing the manifest clutter.

@FranzBusch WDYT?

@Helge_Hess1

But even that is separate, my main issue is feature disparity between regular NIO and concurrency in the base library

in general i have found the newer channel interfaces to have fewer problems with swift concurrency than the old handler interfaces.

one thing i would suggest (for NIO) is promoting the HTTPByteBufferResponsePartHandler mentioned earlier to an actual library API. i actually re-invented the same type about a month ago when i was dealing with the same IOData-concurrency problem, so there’s definitely a need here.