Haha, oh wow. At least this proves the concept to be good :)) Well, my plugin ended up being a bit more complex than initially thought. I just wanted to work close to the RFCs (which includes proper content negotiation.) The broad support of compression algorithms has its roots in a "because it can be done" attitude on my behalf. Most of the time (x-)gzip will be selected by the plugin anyway. I'm currently toying with the idea of letting the admin decide which algorithms are available via the plugin's config page. That way compression algorithms causing problems (e.g. lynx/elinks seems to have issues with this plugin. I cannot tell if that's because lynx' compress is broken or if I've done something wrong. I suspect later one.) can be switched of selectively while preserving general functionality.
As for your code: You might want to consider using gzencode() instead of manipulating the output of gzcompress(). Also, I find your compression level a bit high. IMHO anything above 6 has little gain over a lot of additional CPU cycles. But I really like your idea for a threshold... Mind if I put that as an option into the next version of my plugin? Have fun, Da:Sourcerer -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev To unsubscribe, reply using "remove me" as the subject.
