Because the great master Grady Booch taught us that a class should be
minimalistic and complete. It should contain absolutely everything that
is essential to it's named purpose and absolutely nothing that isn't.
Compression is a separate function from HTTP. It's not in the spec
whatsover, just like JPEG, GIF, and shockwave. If you say that you're
going to put a compression algorithm into the library, then you need to
put algorithims for all MIME types in there as well and your library
just became a disaster.
A good HTTP client library should handle everything that is HTTP and is
a part of the zillion RFCs or other standards that are commonly used.
Since compression is really a MIME type, it should be handled separately
from the client library.
Besides, java comes with libraries for handling zip files. Just wrap the
return value in that.
Tony Thompson wrote:
I thought I would chime in and say that I disagree. As a user of the
HTTP library, why shouldn't I be able to tell the client to do
compression, if it can negotiate it with the server? Then, when I grab
the content from a response, I should be able to get the uncompressed
content seamlessly. I think it would also make sense to have the option
to get the response content in its compressed form as well. Doing it
that way, that still leaves it totally up to the user if they even want
compression and they have access to both the compressed and uncompressed
response. I think that makes more sense than forcing everyone to
implement compression themselves.
Just my 2 cents...
Tony
[EMAIL PROTECTED] 12/10/05 10:42AM >>>
FWIW, I agree with you, Oleg.
Oleg Kalnichevski wrote:
On Sat, 2005-12-10 at 14:16 +0000, sebb wrote:
I've searched the documentation and source, and the only references
to
zip / compression seem to be in the content-type lists. [Also
searched
Bugzilla]
Just double-checking:
It seems that HttpClient does not automatically handle compressed
responses.
Is this the case, or have I missed something?
This is indeed the case.
Asuming no, are there any plans to include decompression in the
future?
No. There are no such plans. HttpClient should not have any content
processing code. Compression / decompression logic can be easily
built
on top of HttpClient. Anything that has to do with the content
processing does not belong to a generic HTTP library
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]
Thom Hehl
Heavyweight Software for Heavyweight Needs
www.heavyweightsoftware.com
Thom Hehl
Heavyweight Software for Heavyweight Needs
www.heavyweightsoftware.com
--
"In every revolution, there is one man with a vision."--Jerome Bixby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
