Am 2019-11-26 um 22:10 schrieb Gary Gregory:
One item that remains for me is to fix the consistency in naming of types.
This is new code that will live for loooong time, so let's make it the best
we can please. For example, we mix call CAPS and CamelCase for acronyms:
For example, these two sit right next to each other in the same package:
org.apache.hc.core5.reactor.ssl.SSLSessionVerifier
org.apache.hc.core5.reactor.ssl.TlsDetails
Can we pick ONE convention please, either:
org.apache.hc.core5.reactor.ssl.SSLSessionVerifier
org.apache.hc.core5.reactor.ssl.TLSDetails
or
org.apache.hc.core5.reactor.ssl.SslSessionVerifier
org.apache.hc.core5.reactor.ssl.TlsDetails
I don't care which one at this point. We do Use "*Http*" a lot so that
might be a hint to pick that style. I'm happy to provide a PR once we agree
I think there is a rule of thumb in Java: if the abbreviation is at most
3 chars, you can keep it uppercase, otherwhise make it PascalCase, not
camelCase for class names. But anyway, make it consistent.
As a side note, why keep SSL in the name at all, we only use TLS these
days...?
--
We also have a mix of "Http", "Http1", H2" which I find confusing. In the
httpcore5-h2 module we have:
org.apache.hc.core5.http2.impl.nio.ServerH2StreamMultiplexerFactory
org.apache.hc.core5.http2.impl.nio.ServerHttpProtocolNegotiator
org.apache.hc.core5.http2.impl.nio.ServerHttpProtocolNegotiatorFactory
Why is it not:
org.apache.hc.core5.http2.impl.nio.ServerH2ProtocolNegotiator
org.apache.hc.core5.http2.impl.nio.ServerH2ProtocolNegotiatorFactory
I agree here. The package name could have been h2 also.
I find it weird to have "Http1" vs. "H2", it feels like another
inconsistency.
I would avoid using terms like HTTP1 or Http1 because they have never
been used throughout the net. Either Http10, Http11 or just Http. H2 is
HTTP/2. Period.
Michael
On Tue, Nov 26, 2019 at 8:55 AM Oleg Kalnichevski <ol...@apache.org> wrote:
Folks
How do feel about releasing HttpCore 5.0 GA next week and HttpClient
5.0 shortly after?
In the next development phase I imagine we could backport some of the
5.0 code to 4.x. HttpCore 4.x and HttpClient 4.x could benefit from
better connection pool implementations from 5.0.
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
