You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2007/07/15 12:22:23 UTC
[HttpCore] HttpParams interface was Re: [Jakarta-httpclient Wiki]
Update of "GuidedTourOfHttpCore" by RolandWeber
Roland Weber wrote:
...
>
>> PS: on a side note, because that was one thing I was wondering about:
>>
>> From a framework perspective, parameters are read-only.
>>
>> Was it too difficult to use in the client or why didn't you make the
>> HttpParams interface readonly and provided a subinterface (for use in the
>> helper classes HttpProtocolParams and HttpConnectionParams) with the setter
>> methods? Since the core doesn't need the setter methods it looks like the
>> way to go to design the interface.
>>
>
> Actually, I haven't tought about it that much. It is easier to use
> for applications, because they must modify the parameters before
> passing them to the core. Splitting in two interfaces for reading
> and writing is something I'll consider for a while.
>
> Oleg, others, what do you think?
> interface HttpParams
> interface ModifiableHttpParams
>
> Some of the parameter stuff I want to introduce in client alpha2
> will be read-only anyway. I thought about throwing an exception
> in setParameter, but having a read-only interface would be better.
>
>
Do you still envisage the following way of setting HTTP parameters?
httpclient.getParams().setParameter("whatever", someObject);
or with the suggested change in place one would have to provide a whole
new instance of HttpParams in order to change a single parameter?
BasicHttpParams params = new BasicHttpParams();
params.setParameter("whatever", someObject);
httpclient.setParams(params);
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpParams interface
Posted by Roland Weber <os...@dubioso.net>.
Oleg Kalnichevski wrote:
> I tend to dislike downcasts.
So do I.
> Besides, that implies every class that
> implements HttpParams must also implement ModifiableHttpParams as well
> to be of any use.
What about this?
HttpParamsStack hps = new HttpParamsStack
(requestParams, clientParams, appParams);
Because that's the basic idea I want to pursue
for the client parameter stack we've discussed.
> Anyways, there are different ways of looking at things. So, I will not
> object if you do it differently.
I'll think about it. There are plenty of other things
on my list with a higher priority. If I don't come up
with a patch before the next core release, that means
I've given up on this idea.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpParams interface
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2007-07-15 at 12:51 +0200, Roland Weber wrote:
> >> interface HttpParams
> >> interface ModifiableHttpParams
> >>
> > Do you still envisage the following way of setting HTTP parameters?
> >
> > httpclient.getParams().setParameter("whatever", someObject);
>
> Hm, no, not really. Should we encourage modifying parameters
> that are already passed to the framework in the first place?
>
> > or with the suggested change in place one would have to provide a whole
> > new instance of HttpParams in order to change a single parameter?
> >
> > BasicHttpParams params = new BasicHttpParams();
> > params.setParameter("whatever", someObject);
> > httpclient.setParams(params);
>
> No, no new instances. But a downcast will be needed.
>
> ((ModifiableHttpParams)client.getParams()).setParameter
> ("whatever", someObject);
>
> or if there is a helper:
>
> HttpClientParams.setParameter(
> ((ModifiableHttpParams)client.getParams(), someObject);
>
I tend to dislike downcasts. Besides, that implies every class that
implements HttpParams must also implement ModifiableHttpParams as well
to be of any use. So, what are we really gaining here?
Anyways, there are different ways of looking at things. So, I will not
object if you do it differently.
Oleg
> We can consider to include the downcast in the helper.
> I'd also prefer a shorter qualifier than "Modifiable",
> but RWHttpParams is inconsistent with our current naming
> schemes. And it looks ugly, too.
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpParams interface
Posted by Roland Weber <os...@dubioso.net>.
quick update...
>>> interface HttpParams
>>> interface ModifiableHttpParams
>>>
>> Do you still envisage the following way of setting HTTP parameters?
>>
>> httpclient.getParams().setParameter("whatever", someObject);
>
> Hm, no, not really. Should we encourage modifying parameters
> that are already passed to the framework in the first place?
Within core, only AbstractHttpMessage creates params internally
and requires a downcast for modification. In client, it's the
DefaultHttpClient, and only as a fallback if no parameters are
passed to the constructor or set explicitly.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpParams interface
Posted by Roland Weber <os...@dubioso.net>.
>> interface HttpParams
>> interface ModifiableHttpParams
>>
> Do you still envisage the following way of setting HTTP parameters?
>
> httpclient.getParams().setParameter("whatever", someObject);
Hm, no, not really. Should we encourage modifying parameters
that are already passed to the framework in the first place?
> or with the suggested change in place one would have to provide a whole
> new instance of HttpParams in order to change a single parameter?
>
> BasicHttpParams params = new BasicHttpParams();
> params.setParameter("whatever", someObject);
> httpclient.setParams(params);
No, no new instances. But a downcast will be needed.
((ModifiableHttpParams)client.getParams()).setParameter
("whatever", someObject);
or if there is a helper:
HttpClientParams.setParameter(
((ModifiableHttpParams)client.getParams(), someObject);
We can consider to include the downcast in the helper.
I'd also prefer a shorter qualifier than "Modifiable",
but RWHttpParams is inconsistent with our current naming
schemes. And it looks ugly, too.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org