> If we are not going to use compression, or we are handling it in > our own code, why link the zlib library?
You said you are not using the v7 component, so none of this currently effects your applications. It is not realistic to make the code more complicated just to satisfy compatibility for one user that may or may not use it sometime in the future. Now that content encoding is available for all component users, your own code could be abandoned so it's a non-issue. The size increase adding the zlib code is not that much, about 21K, particularly compared to the vast Delphi visual runtime library that brings in hundreds of kilobytes of components that are rarely used, like action lists, image lists, docking, etc. > And the other suggestion to always call the OnContentEncode, if > assigned and hoContentEncoding in server options, despite the > internal content type and stream size checks? That would mean the user had to repeat the content type and size tests in the event, before deciding whether to look-up a cached compressed file. But I accept the tests need to be improved, I forgot about compressing XML content for instance. So I will move the tests into a virtual function that can be overridden in an application to give total control (and save some duplicated code). Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
