On Sat, Mar 06, 2010 at 05:01:03PM +0100, Daniel Stenberg wrote: > On Sat, 6 Mar 2010, Olaf van der Spek wrote: > > >>Because nobody ever asked for one before, until you did now... > >>And frankly, I don't see the point since it's so little extra > >>code to do your own. > > > >Would you be interested in a patch to add such a function? > > Not until at least someone else also speaks up in favour of it. Then > there's of course the issue of how an API for such a function would > work, and then I'm mostly thinking about how the app would know how > each individual transfer did.
I'd like to speak out against such a change. While I realize some applications would always benefit from the use of compression, there's no way to guarantee that it's always a sensible default. If libcurl doesn't send any accept-encoding header and it is desirable to send one by default, my suggestion would be to use "identity" as the default. The data transferred by our application is already compressed, but the metadata is not. Our application sets this header when it's requesting metadata, but not data. In most cases, the requested content is already compressed, and it would be counterproductive to have the server try to perform a second compression as part of the download. It is straight-forward to write a per-application function that sets up the defaults on easy handles. That's what we did for our application. I don't see what's wrong with having an application explicitly request the features that it desires. Enabling compression by default isn't necessarily going to increase performance by default. On low-latency high-bandwidth links, this may even cause performance to decrease. -j ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
