-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I think it could be, the API is of course still young, but the design
> was that WebResource encapsulates functionality of a resource, and
> there may be different requirements for client communicating with the
> resource. IIRC there were already some people setting the time out
> options for different resources, another one could be redirection,
> sometimes you need to, other times not. Same for credentials. Having
> to have a new Client instance for each configuration is expensive.
>
I see.
> Looking closer at the Apache HTTP client API it appears that:
>
> - HostConfiguration, HttpState can be passed to
> HttpClient.executeMethod(...); and
>
> - It is possible to set parameters to the HttpMethod using
> HttpMethodParams, which
> is a super class of HttpClientParams. The only feature that
> requires HttpClientParams
> is HttpClientParams.setAuthenticationPreemptive.
>
> In this respect it seems possible to get most functionality working in
> a thread safe manner using the existing configuration approach. Is
> that your understanding as well?
>
>
Yes, I believe this is true.
> I am open to suggestions on how we can change the API to support both
> the HttpURLConnection and Apache HTTP configuration approach.
>
> There seem to be two sets of configuration options:
>
> 1) options that are configurable once per root client handler.
>
> 2) options that are configurable by the client, filter and
> WebResource at runtime.
>
We could take the approach that HttpClient takes and actually have two
different classes of configuration options. That makes the distinction
that you're pointing out clear to the developer.
Another approach we could borrow from HttpClient is to pass
configuration options directly to the Methods themselves. That makes the
configuration ephemeral and we could say things like redirect in general
but please don't redirect on this DELETE.
> Maybe the root client handler can also implement another interface
> with an initialization method that takes the client config and looks
> at certain properties that only apply to initialization e.g. the
> preemptive auth.
>
I agree there needs to be a better connection between the root handler
and the config.
> In addition it might be possible to support an efficient Client.clone
> method.
>
I'd much rather keep around multiple HttpStates, and Configurations and
swap carefully between them than to have multiple HttpClients. As I
understand, HttpClients are pretty resource heavy. Keep in mind that
the connection manager associated with the client may actually open
multiple connections to the server for example....
On a side note, I keep debating whether to offer that as a configuration
option -- the total number of maximum connections, and the maximum
connections to a host --- see MultiThreadedHttpConnectionManager.
- -jOrGe W.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkuSo4ACgkQ72r0i/n44hNU7gCfWT6qkRxCDwfUm6AXb7HKYm9Y
hYgAoLjCO8A+zOA+hodOQYnmikT0CMkg
=Ivgn
-----END PGP SIGNATURE-----