On Nov 25, 2008, at 9:05 PM, Jorge L Williams wrote:
>
> Hi Paul,
>
> Sorry for the late reply I've been really busy today.
>
No problem.
> I should have been more specific in my e-mail. Requests are thread-
> safe you can have multiple connections and they should be handled
> in a thread-safe manner. Multiple-threads can share connections in
> fact. But you're right, you can't change the configuration in a
> thread-safe manner. I was under the impression, from reading the
> JavaDocs, that this was also the case with the URLConnection
> backend so I didn't worry to much about it.
>
> Can you give me an example of when a WebResource would configure a
> property? I'm just curious if this is a common case.
>
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.
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?
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.
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.
In addition it might be possible to support an efficient Client.clone
method.
Paul.