Hi Adrian, Are you speaking of HTTPClient 4.0?
We currently use HttpClient 2.0-beta 2 with a few small modifications because it's been working exceptionally well for us. Any changes to design obviously would have to go into a future version so probably 4.0 or perhaps even later than that if it's possible at all.
We are using HTTPClient 2.0 in production, and have a requirement to only read x number of bytes of the body. For a while we were reading the whole body and throwing away the unwanted bytes, but for 70meg files this proved problematic for performance reasons, when we only wanted 50K. So we have overriden HTTPClient to stop reading at some arbitrary MAX body size, and we release the connection.
I'd actually forgotten this wasn't possible in 2.0 - if I recall correctly, 3.0 adds an abort method which allows you to abort reading the connection and close the input stream.
My preference would be if we can work within the limits of the InputStream API with the HttpClient API isolated to just when the connection is first made. That way you can have a single class that wraps HttpClient and provides a simpler interface to download a file, handling response codes and any settings on HttpClient etc transparently to the caller and returns an InputStream. The caller can then work with the InputStream like any other without considering that it came from HttpClient and expect things to work.
Essentially, the power of HttpClient with the simplicity of URLConnection.
Steve Johnson, Software Engineer, [EMAIL PROTECTED] direct 720.564.6532 www.mercury.com
Regards, Adrian Sutton. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
