Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mark Adler's reaction #6

Closed
GoogleCodeExporter opened this issue Mar 9, 2015 · 3 comments
Closed

Mark Adler's reaction #6

GoogleCodeExporter opened this issue Mar 9, 2015 · 3 comments
Labels
auto-migrated Priority-Medium Type-Defect

Comments

@GoogleCodeExporter
Copy link 

Mark Adler who wrote Zlib with Mark Nelson just expressed its feelings about 
Zopfli on the [Zlib-devel] mailing list:
"That's cool, but it seems like an awful lot of effort for a small improvement. 
 Perhaps it's time to add a better compression method to HTTP's 
accept-encoding."

I can only agree, Deflate was written around 1994 (when operating systems like 
Windows 95 required 24MB of main memory and Unicode was a toddler), its 
definitely time to move on!
Even ZIP archives can handle better compression algorithms (Deflate64, bzip2, 
PPMD, LZMA) since years.
WebP has a search window that is way larger than Deflate (32k), HTML5 only 
recommends UTF-8 encoding and Deflate is still single byte oriented... imagine 
how poorly it performs on pages holding text written in Devanāgarī (3 bytes 
per Unicode code point in UTF-8, main script used by nearly half of the 
population in India).

Original issue reported on code.google.com by cryo...@free.fr on 3 Mar 2013 at 7:13
@GoogleCodeExporter
Copy link
Author 

This is missing the point. The point is that Zopfli is compatible with the 
existing deployed base of BILLIONS of clients. No new scheme would be. The 
original version of Chrome supported BZIP2 "just because" but it was pulled out 
after it was determined that it caused problems with intermediaries.

More interestingly, even though other algorithms (e.g. LZMA) generate smaller 
output, the new SPDY protocol (which doesn't require back-compat) is based on 
GZIP/DEFLATE, most likely for ease-of-porting and performance on low-spec CPUs.

Original comment by bay...@gmail.com on 7 Mar 2013 at 6:18

@GoogleCodeExporter
Copy link
Author 

The same goes for WebP vs PNG or JPEG, would you say to the folks behind it 
that it's a worthless effort since PNG and JPEG are already available in all 
the browsers?
Innovation will not stop because there's something already deployed at large 
scale and since years, the main problem is to move smoothly from something that 
has wide acceptance to something new.

Nowadays we have atrocities like the "data:" URL scheme (RFC2397) that's base64 
encoded binary files embedded in HTML or CSS files, Deflates knows nothing 
about base64 (advanced compressors decode the base64 data and reencode it that 
way during decompression) the best Deflate could do at this level is produce a 
block that would just fit the base64 part.

SPDY is not there to last as it will be replaced by HTTP/2, and HTTP header 
compression based on Deflate is no longer an option for HTTPS since it is 
subject to the "CRIME" security exploit.

Original comment by cryo...@free.fr on 8 Mar 2013 at 12:52

@GoogleCodeExporter
Copy link
Author 

Acknowledged. Closing because it is not Zopfli specific.

Original comment by l...@google.com on 10 Jul 2014 at 3:10

  • Changed state: WontFix

kornelski pushed a commit to ImageOptim/zopfli that referenced this issue Dec 3, 2018
@carols10cents
Merge pull request google#6 from shepmaster/all-rust-types
5324e24 
Replace C types with Rust types
@neheb neheb mentioned this issue Jun 17, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Priority-Medium Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter