> 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). 


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

Reply via email to