HttpClientContext does seem to have an "adapt" function as its main use
(I'm only going by the javadoc "Adaptor class ..."). The "Client" is a
throwing in a hint that is a bit strange as HttpContext goes with
HttpClient.
Mixing the two gets into yuky-ness if the application provides a
HttpContext, then Jena wraps it ... then set() and get() are different
objects. A bit confusing rather than broken. And some casting weirdness.
It seems to me that we could have used HttpClientContext consistently
everywhere ... but we didn't and to introduce it is a contract change
whereas widening to HttpContext isn't.
Andy
On 27/04/17 16:04, [email protected] wrote:
I think this is indeed where we are getting to (that client and context
need to be fully threaded through the whole API). That's kind of the
price we pay to avoid doing lots and lots of work to hide them.
I'm not as sure that context without client works as well... but it does
seem from the HTTP Commons API itself that they are designed to be
separable...
I used HttpClientContext because I thought it best to expose that
type-safety from the HTTP Commons API outwards, but (as in your current
PR) I don't have strong feelings about it.
---
A. Soroka
Andy Seaborne wrote on 4/27/17 6:56 AM:
(triggered by the question on users@ about RDFConnection and
HttpClient => JENA-1330)
Q:
For API operations that take an HttpClient argument, should there
always be a variant that accepts an HttpClient and a HttpContext?
From looking at the code, there is also a possible HttpContext to
apply to use of HttpClient. It means one HttpClient can be reused in
different ways with
different HttpContexts.
Also (OK - this is a second question :-)
HttpClientContext seems to be a wrapper of an HttpContext to provide
convenient names and typesafe operations on an existing HttpContext.
If so, HttpQuery (etc) should have a HttpContext, not a
HttpClientContext, and adapt the HttpContext at the point of applying
operations?
Andy
