On Thu, Mar 11, 2010 at 2:16 AM, Gary Maxwell <[email protected]> wrote: > 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.
No, I'm asking people to fix their server configs. >> 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. To me, it seems perfectly reasonable to compress 8 kb (assuming it can be significantly compressed). >> 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. Only when the server's config is wrong. > It adds complexity when applications suddenly break when the libcurl library > is silently upgraded as part of an automatic update for servers and desktops. Again, IMO, that's a server-side bug. If apps fail due to this, it might be a good idea to fix stuff regardless. Olaf ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
