hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 28 Jan 2014 12:36:29 GMT
On Tue, 2014-01-28 at 11:49 +0000, sebb wrote:
> On 28 January 2014 08:28, Oleg Kalnichevski <olegk@apache.org> wrote:

...

> One way is trial and error by source comparison.
> It would be tedious. If Google took a formal release (rather than a
> snapshot) then the process would be a lot quicker of course.
> 

Tedious and almost useless given the net gain.   

...

> >> > If you are familiar with Spring, think of Spring Rest template.
> >>
> >> No, I'm afraid I have no experience of Spring.
> >>
> >
> > I hope this will help you understand what I am trying to achieve and why
> > it is important:
> >
> > http://docs.spring.io/spring-android/docs/1.0.1.RELEASE/api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#setHttpClient%28org.apache.http.client.HttpClient%29
> 
> I see.
> 

Ah.

> However, this will only work reliably if the application avoids using
> any implementation classes that have been replaced in the new library.
> 

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.

The whole is not to provide a drop-in replacement but a backward
compatible alternative with fewer bugs and more features, which can be
used with all those 3rd party libraries such as Spring for Android.

> ==
> 
> The README talks about ensuring compatibility between Android and Java
> applications by avoiding certain classes.
> Maybe the original classes need to be tagged in some way in the Java
> source so that people developing Java applications have advance
> knowledge of which classes won't be available on Android. If the
> tagging were done consistently, it could then potentially be used to
> drive the "shading" process, avoiding the need to include magic
> strings in the gradle script.
> 

I really would not like to pollute the stock version of HttpClient with
Android specific stuff, hence my intention to keep most of the migration
logic in the script even at the price of having to employ some dark
magic. 

This port is a stopgap solution until the next major release (which is
still in some distant and uncertain future). It should eventually
disappear. 

Oleg


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


Mime
View raw message