1 Jul 02:33
Re: gzip/deflate compression/encoding
Laird Breyer <laird <at> lbreyer.com>
2005-07-01 00:33:52 GMT
2005-07-01 00:33:52 GMT
I think this thread is getting bogged down in technical points without a clear overview. Rather than respond to each good point you've raised, I'd like to try another line which broadly summarizes my view and is perhaps more useful to the list. I generally agree with you that double compression is useless, where we differ is where the single compression step should be applied. You propose that it should occur in the MIME format, while I still believe it should be a transparent service at a level much closer to the OS. Since XML data seems to be the main beneficiary mentioned thus far of the CTE (37% base64 overhead aside), let me ask what the proponents aim to achieve in this instance? Other media types such as audio/video/images are already compressed so won't benefit substantially from a CTE. Is the idea of CTE compression simply a way to pass the burden of XML compression onto another system level? XML is by design a textual format. An explicit goal of this format is the ability for humans and other programs to easily read and modify it. The internet message format has similar goals, although MIME more generally may not. If space is such a serious concern, I ask: why shouldn't XML applications simply read and write XML directly in compressed form when needed (you already gave the example of OpenOffice) ? There would be no need for MIME readers and writers to be adapted at all, and the physical benefits would be comparable.(Continue reading)
*/
do while INPUT \== '' /* strict comparison */
parse var INPUT TOP 2 INPUT
TOP = d2c( c2d( TOP ) + 64 ) // 256 )
if sign( pos( TOP, BAD )) then OUT = OUT || '='
OUT = OUT || TOP
if LIM <= length( OUT ) then do
call charout /* stdout */, OUT || CRLF
OUT = ''
end
end
> If not, then you are back to the 37+% expansion of base64.
RSS Feed