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]
