hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 04 Feb 2014 15:12:23 GMT
On 31 January 2014 09:25, Oleg Kalnichevski <olegk@apache.org> wrote:
> Sebastian, Gary
>
> So, what is the outcome of this discussion?
>
> I amended the content of README file based on your feedback. HttpClient
> for Android is no longer referred to as a re-spin but rather a port. I
> also reworked the compatibility notes to make them less complex.
>
> Do you object in general to adding a page about this port to the project
> web site, inviting the users to try out the snapshot and soliciting
> their feedback?

I have updated the download section as only official releases should
be promoted.

> Based on the feedback we can still decide how to proceed further.

My concern at present is that the process for building the port is
insufficiently documented.
There are almost no comments in the gradle scripts, so it is not clear
what the various lists of class names represent, nor how to maintain
them if changes are made to the stock source.

Also most files need AL headers.

> Oleg
>
> On Wed, 2014-01-29 at 09:57 +0100, Oleg Kalnichevski wrote:
>> On Tue, 2014-01-28 at 19:39 +0000, sebb wrote:
>>
>> ...
>>
>> > >
>> > > Why? The new implementation honors the same contract by implementing the
>> > > same interfaces and using the same API classes as the old version. As
>> > > long as the application does not directly depend on the old
>> > > DefaultHttpClient (in which case we cannot do much) but rather relies on
>> > > HttpClient interface, the newer implementation can be used without any
>> > > alternations.
>> >
>> > Suppose the code depends on the class
>> > org.apache.http.entity.HttpEntityWrapper
>> >
>> > This won't exist in the new jar as it is one of the HC4-suffix classes.
>> >
>> > Assume also that the new HttpClient implementation makes use of the class
>> > org.apache.http.entity.HttpEntityWrapperHC4
>> >
>> > Seems to me that this could well cause a problem where the app works
>> > fine on Java but fails on Android - and the failure could be very
>> > tricky to debug.
>> >
>> > That's why I think the application needs to avoid using the classes
>> > that are renamed with the HC4 suffix.
>> >
>>
>> It is theoretically possible but not very likely. Besides, HC4 classes
>> are absolutely no different from any custom interface implementation or
>> a custom subclass HttpClient must be able to handle. This is no
>> different from hitting a perfectly ordinary bug. HC4 classes are just
>> ugly. This is the only problem with them.
>>
>> I could make some (probably most) of those classes package private, but
>> a few utility classes are being used all over the place and need to
>> remain public.
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Mime
View raw message