Olaf van der Spek intoned on Wednesday, March 10, 2010 4:10 PM:
>
> Yes, I understand your case. Although in that case the code wouldn't
> change much. You'd just disable that header instead of enable it in
> certain cases.
>

Are you asking people to change existing, stable code which works fine right now? That may be fine if the original developer is still around, not so fine if the remaining developers treat libcurl and the code which accesses it as a black box.

> >
> > Maybe, but that's not the point.  We all have to exchange data with
> > servers that, like the one I have to use, have a naive concept of how
> > and when to use compression.  We're using CherryPy 3.X, if the
> > accept-encoding header specifies a type of encoding that the server
> > supports, it will make a best effort attempt to compress the data.
>
> So because some servers don't have proper logic to decide on
> compression, we should disable compression in the client by default?
>

Interesting you should pose this as a rhetorical question when compression is already disabled by default.

Some clients (mine) do not use compression, and will never use compression due to memory footprint issues and small size (1K ~ 8K) of the datasets downloaded with libcurl.

> >> > I don't see what's wrong with having an application explicitly
> request
> >> > the features that it desires.
> >>
> >> Global code complexity...
> >
> > Except that's not true.  In the situation that I've described, your
> > proposed change only adds complexity.
>
> Why?
> Instead of code to enable it in some cases, you have code to disable
> it in the other cases.
>

It adds complexity for existing libcurl users who will be forced to modify their libcurl application when they upgrade the library, which in turn adds additional regression testing.

It adds complexity when applications suddenly break when the libcurl library is silently upgraded as part of an automatic update for servers and desktops.

Cheers,
GaryM @ Casabi

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-03-11