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? Based on the feedback we can still decide how to proceed further. 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
