GZip level restriction

[Derek Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

I discussed adding a compression level restriction on the server as a
work-around for another bug that has since been fixed a few months back.

I can't find the email, but I believe Mark Baushke suggested a
restriction format like:

AllowedGZipLevels=0123456789

where 0 meant allowing no compression, and failing when the level
requested by the client was not in the list.

I think I actually prefer something more like:

DefaultGZipLevel=6
MinGZipLevel=3
MaxGZipLevel=6

and code that says:

if (level == 0) level = DefaultGZipLevel;
if (level < MinGZipLevel) level = MinGZipLevel;
if (level > MaxGZipLevel) level = MaxGZipLevel;

In preference to actually issuing an error, though perhaps a warning
would still be appropriate.  This way, users that put "cvs -z9" in their
.cvsrc will always get the maximum gzip level allowed by any server and
still be able to use their .cvsrc with all the servers they access. 
Also, decompression is much less CPU intensive than compression, so it
shouldn't hurt to let the client compress at whatever level it likes and
clients should still use level 9 for compression in this scenario, and
the server would use whatever was declared its max level.

Just wanted to run this by the list before I begin coding.  I suppose
that all four config keywords could be added.  Then, default, min, and
max could be processed as I am suggesting and AllowedGZipLevels could be
used if an admin wanted their server to emit real errors for some
reason.  I'm not sure I see the utility here, though, so I'd just as
soon leave it out unless someone can come up with a believable scenario
which demonstrates its utility.

Cheers,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjiRpLD1OTBfyMaQRApggAKDewo8mJtB5OEiYRn3Dtt1o9Ljm0QCeIZEY
SC55YocLuAh4P8bMPQN6KaA=
=y45z
-----END PGP SIGNATURE-----