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
Received on 2010-03-08