| |||||||||||||
Google releases a better compression algorithmGoogle releases a better compression algorithmPosted Mar 1, 2013 9:27 UTC (Fri) by nim-nim (subscriber, #34454)In reply to: Google releases a better compression algorithm by rahulsundaram Parent article: Google releases a better compression algorithm
Actually, what compression method to use is one of the hot topics of the ietf workgroup currently working on HTTP/2, and Google is a major contributor to those talks. There is no reason for HTTP/2 to use the same algorithms as HTTP/1, and the use-cases presented in the sopfli paper are definitely the same as HTTP/2.
(Log in to post comments)
Google releases a better compression algorithm Posted Mar 1, 2013 15:19 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>here is no reason for HTTP/2 to use the same algorithms as HTTP/1
Indeed, and therefore, HTTP/2 could just as well use xz. (Or any other established LZMA-ish compressor, but picking xz would follow suit with gzip, which was also used for files and tarballs.)
That, and LZO for the ones who like a trade-off into speed over ratio.
Google releases a better compression algorithm Posted Mar 2, 2013 7:55 UTC (Sat) by epa (subscriber, #39769) [Link]
Google has a replacement for LZO: http://code.google.com/p/snappy/
Google releases a better compression algorithm Posted Mar 3, 2013 2:08 UTC (Sun) by scientes (guest, #83068) [Link]
xz is officially lzma2, as used the same liblzma as the original legacy lzma1. Basically people used lzma before it was ready, so they renamed the final version to avoid confusion over the incompatibility. lzma is now a symlink to xz.
both lzo and xz are very useful, but for differn't things, lzo is most useful when only using the compressed data once, and xz when it is write-once read-many, so you can afford the high compression times and memory requirements.
|
|||||||||||||