Because of the nature of PGV, I feel it's a good idea to use the zlib
output compression. After having seen it in the README, I had
this in my .htaccess, but I suggest that this be made into a config
option. If the admin sets compression on, PGV should check if the
modules exists (on my server, some days they do and somedays
they don't, leading to internal server error) and then turn
compression on. It's a real saver on bandwidth.
> KosherJava had replied:
> Using zlib compression is mentioned in the README quoted
>below. Since it can cause problems in certain conditions (as
>mentioned below) , it was not added to try and reduce the
>support questions to the PGV developers. It also increases the
>workload of the server and this will be an issue to some. Also
>remember that not all servers use .htaccess files.
My suggestion was make this into an admin config option.
And to ensure that it won't break anything, check what
compression the host (can) use first, if any at all.
I was suggesting to put it into the config as something like:
if ($config_use_compression) { // some admin config variable
if (check_if_zlib_module_installed) {
ini_set('zlib.output_compression', 'ON');
ini_set('zlib.output_compression_level', '5');
} elseif (check_if_xyz_compression_module_installed) {
// initiate alternative compression
} elseif (check_other_common_compression_module_installed) {
// initiate alternative compression
} else { // do nothing / no compression}
}
The benefits:
1) compression defaults to false/none for existing and new users
2) compression can easily be turned on/off by the admin
3) appropriate compression for the host can be used
4) no need for .htaccess files for hosts that can't/don't use them
5) can protect against changes in the host server's configuration,
upgrades (when the compression module is accidentally forgotten),
etc. without bringing down the site. (500 internal server error)
If the code is intelligent, then there would be no extra support
requirements from the developers other than: "turn compression
off". Even that would be rare since it wouldn't be (turned) "on" if the
server didn't support it anyway.
I understand it's more server intensive, but if/since the default is off,
it would only affect those who turn it on by choice after knowing
that reducing bandwidth comes at the cost of increased server
workload. (nothing is free!)
> It might not be that easy (will have to work on all servers that
> support PHP) but it will be trackable if you fill out an RFE.
I can understand the complexity. It just SEEMS simple to do! :-) I
would give more details or write the code myself, however, I don't
know how to check if a module is installed or supported. (/me
rummages through php manual again....)
Since the PGV readme only mentions zlib, how about starting out
with just checking for the zlib module, rather than checking for all
possible or common compression methods? Checking for other
modules can be added later.