Hi Oleg, Thank your for starting this conversation. More below.
On Mon, Mar 11, 2024 at 10:11 AM Oleg Kalnichevski <ol...@apache.org> wrote: > > HttpClient 5.4 is going to be the most feature rich minor release > probably since 4.3. There are plenty of small and not so small features > and improvements in it. Overall it is going to be a great release. > > It will likely take a few more months to stablize it but somethime > around mid Summer we should be able to release the first GA. That is > the plan. > > However beyond 5.4 our development plans are unclear. We can settle for > no particular plan and simply react to feature requests from our users > or we could invest some efforts and time proactively. Both approaches > are perfectly valid given the scarcity of project resources. > > If we choose a more proactive stance there are several potential > features we could work on > > > core: > > * Better / more efficient implementation of channel (socket) timeout > handling in the async i/o reactor. What we currently have is quite bad > for a large number of concurrent sessions I like the idea of cleaning up cruft we know about (not that I am the one that will do that specific work, so it's easy for me to say). > > * CONNECT method support and connection tunneling for HTTP/2 > > > * HTTP/2 for the classic transport (now with introduction of virtual > threads (fibers) in Java 21 we could revisit the issue of the classic > i/o model not working well for multiplexing protocols and try to solve > the problem by utilizing two fibers per HTTP/2 data stream) I like the idea of taking advantage of Java 21's virtual threads. At worst, we should be VT-friendly, meaning, addressing any performance or usage issues, without rewriting everything. Pinning seems to be a recurring issue I hear about in different projects. Addressing anything missing from our HTTP/2 (or 1) support, sounds good. I'm not sure how to prioritize that over HTTP/3 and QUIC. My first impression is that feels better to think about improving what we have before taking on new large tasks. > > > * JRE level upgrade I would like to see the JRE platform raised to Java 17. My day job has migrated our products from 8 to 17 last year. We're not quite ready for 21 but I am OK if we migrate to 21 here. Is the target our 5.5.x line? Or would a hop to 17 be a 6.0? That does not seem necessary. Unless virtual threads makes us rethink so much code that we'd want to break BC. > > > client: > > * Multipart entity support for the async transport > > * Transparent content compression / decompression for the async > transport > > * Query timeout / request deadline support > > * JRE level upgrade > > > The real 1'000'000 USD question for us as a project however what the > hell we are going to do about HTTP/3? > > HTTP/3 and QUIC dwarfs everytihng we have done so far in terms of > complexity. Do we have resources to pull it off? Do we attempt to build > our own QUIC layer or do we wait until QUIC is supported and provided > by JRE? Is QUIC even in scope for us? QUIC sounds like a module that is a sibling of HttpCore. I don't know enough about it. Would we provide a common abstraction for our HTTP clients classes? A new client-level abstraction? > > The subject of HTTP/3 support is so big that it probably deserves a > separate discussion. > > What do you, guys, think? How shall we proceed? We should split this thread into 1 thread per topic before it becomes hard to track who's replying to what. Gary > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
