My concern with the core/client split is that I think it exposes tons of additional API surface area which will become a liability post-release. My recent changes for TLS handshake timeouts are a good example of this: in order to use the `connectTimeout` as the TLS handshake timeout (which is basically a bugfix), I had to make breaking API changes to over a dozen public classes, and two interfaces as well (TlsStrategy and TransportSecurityLayer).
The interface changes are particularly worrisome, because after release they'll be more or less impossible; we won't even have Java 8 default methods to fall back on. Core defines over 130 public interfaces, about half of which are new in 5.0, and only four of which are marked @Internal, so our compatibility obligations are clearly daunting. Merging core into client is obviously an extreme suggestion, but I'm not sure how else to attack the root of this problem. On Tue, Dec 4, 2018 at 3:21 AM Oleg Kalnichevski <[email protected]> wrote: > On Mon, 2018-12-03 at 14:11 -0800, Ryan Schmitt wrote: > > I had a few basic questions about the division between core and > > client: > > > > 1. Why the split between core and client? > > > > There are multiple reasons > > 1. Historic / internal ASF politics. > 2. Core has no mandatory external runtime dependencies (other than JRE) > while Client comes with a number of transitive dependencies: slf4j, > commons codec > 3. There are enough cases where core HTTP transport functionality is > perfectly enough, for instances, in reverse proxies or ESBs. > > > 2. Are there consumers of core who don't also consume client? > > > > I believe there are. > > > 3. What determines whether an abstraction lives in core or client? > > (For > > example, > > > > There is no clear-cut policy. Sometimes some things start off in Client > and later get moved to Core, if they turn out to be generic enough (for > example URIBuilder, SSLContextBuilder and connection pools) > Client side state management (cookies), various client side > authentication schemes, client connection routing, hostname > verification, publish suffix lists, etc on the other hand clearly have > no place in Core. Things that drag transitive dependencies with them do > not belong to Core. > > > > 4. Does core contain any interfaces that are intended for client use > > only? > > > > Depends how one defines client use only. HTTP proxies need certain > client side functionality, such as connection pooling. > > > 5. Why is there a dedicated set of client artifacts, but not server > > artifacts? > > > > Because we were mandated to de-emphasize server-side capabilities of > HttpComponents per our project charter. That mattered in year 2005 but > it no longer matters today. If we have enough people interested in > building a stand-alone HTTP server module we can push for revision of > the charter and start publishing purely server side artifacts. > > > 6. Will :httpcore5-h2 be merged into :httpcore5 before release? If > > not, is > > there a reason why it is being kept separate? > > What is the harm in keeping those modules separate? > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
