There is nothing to stop you using alternative compression libraries, I
have applications using different components each with their own versions
of zlib.
Yes, of course, but why increase final application size, and resources
used, if we can simple add the possibility to not duplicate it, if not
needed?
If we are not going to use compression, or we are handling it in our own
code, why link the zlib library?
The workaround to use the ZLibDll could work, but this unit is
loading the DLL at initialization
I don't believe anyone ever used the DLL, once the linked OBJ files
became stable. It's a feature more likely to be removed, than changed so
every unit using zlib breaks.
I don't want to use the DLL version either, I'm running my own encoding
code by handling it thru the OnContentEncode event, so that internal
compression code is never called, but setting it to use the ZLIB DLL
version means the ZLIB obj's are not linked. Just a workaround to
achieve my desire to not duplicate resources.
And, remember, at current version, you are offering the possibility to
use the DLL version, so the proposed fix to load the DLL just when
needed, and check for correct load before calling its functions, is
really a need.
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?
--
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
