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
