HttpParams rename??

[sebb-2-2]

There seem to be quite a few people who assume the HttpParams class is
something to do with parameters used in HTTP requests.

It's probably too late now, but is it worth considering renaming
HttpParams to avoid this confusion? I suspect the confusion will never
entirely disappear.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Sat, 2008-06-21 at 12:00 +0100, sebb wrote:
> There seem to be quite a few people who assume the HttpParams class is
> something to do with parameters used in HTTP requests.
>
> It's probably too late now, but is it worth considering renaming
> HttpParams to avoid this confusion? I suspect the confusion will never
> entirely disappear.
>

I agree, but what do we about the API freeze? Make an exception?

Oleg


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ortwin Glück]

Oleg Kalnichevski wrote:
> I agree, but what do we about the API freeze? Make an exception?

Make a compatible change?
Make HttpParams a subclass of the new one and deprecate it. That should not
break the API.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 21/06/2008, Oleg Kalnichevski <olegk@...> wrote:

> On Sat, 2008-06-21 at 12:00 +0100, sebb wrote:
>  > There seem to be quite a few people who assume the HttpParams class is
>  > something to do with parameters used in HTTP requests.
>  >
>  > It's probably too late now, but is it worth considering renaming
>  > HttpParams to avoid this confusion? I suspect the confusion will never
>  > entirely disappear.
>  >
>
>
> I agree, but what do we about the API freeze? Make an exception?
>

It's a bit different from changing method parameters etc, in that a
simple search-replace can be used, but it would still be a pain for
users.

Maybe it should be raised on the user list.


As mitigation, I think one can keep the old interface and deprecate it.

This could be done by changing HttpParam to ConfigParam (for example)
throughout (only 619 matches in trunk!)

Then make ConfigParam extend HttpParam.
Both would have the same content (Java does not seem to mind this).

Later, the extend clause and the HttpParam class could be dropped.

There are some other classes which perhaps also need to be changed for
consistency:
AbstractHttpParams
BasicHttpParams
DefaultedHttpParams

I think the same "deprecated parent" approach could be used with these
(though obviously the final clauses would need to be removed from the
parent classes).

In the meantime, the Javadoc for HttpParams should be updated; it
would be helpful if it also referenced the classes used for handling
HTTP Parameters.

>  Oleg
>
>
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@...
>  > For additional commands, e-mail: dev-help@...
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 21/06/2008, Ortwin Glück <odi@...> wrote:

>
>
>  Oleg Kalnichevski wrote:
>
> > I agree, but what do we about the API freeze? Make an exception?
> >
>
>  Make a compatible change?
>  Make HttpParams a subclass of the new one and deprecate it. That should not
> break the API.
>

My other posting suggests much the same, except the other way round.

Not sure which is better - the main difference is my method needs lots
of changes to HC code initially, and a simple change when the
deprecated class is removed, whereas yours is the other way round.

But does one interface need to be 'instanceof' the other?
If so, which way round?
This could decide the matter.

>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

Folks,

How about a somewhat different approach?

(1) Leave HttpCore be for now
(2) Make the following changes in HttpClient
   * Introduce ClientConfig interface extending HttpParams
   * Rename all #getParams methods to #getConfig and change them to
     return ClientConfig
(3) Plan for API breakage in HttpCore around late 2009
   * Migrate HttpCore base to Java 5.0
   * Use generics all over
   * Rename HttpEntity#consumeContent to #finish
   * Rename HttpParams interface to HttpConfig


How does that sound?

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...