The proposal does force anything other than gzip to use an alternate code path for parsing/interpretation, which does not inspire confidence given my experience with backup-generator problems, and it probably involves writing *more* code today than the alternative of leaving it where it is in the HTTP semantic layer. -=R On Tue, May 21, 2013 at 2:24 PM, James M Snell <jasnell@gmail.com> wrote: > This does not preclude the use of alternative compression schemes. If > someone chooses, it would be possible, for instance, to continue using > accept-/content-/transfer-encoding at the http semantic layer and > simply not set the GZIP flag on the DATA frame. Having the GZIP flag > would just provide an approach that would make that unnecessary in the > most common cases today. If, at some point in the future a new, more > efficient better compression algorithm overtakes gzip as the > predominant mechanism, the protocol can be updated to reflect that > fact (i.e. with a new protocol version string, etc). > > On Tue, May 21, 2013 at 2:17 PM, Bjoern Hoehrmann <derhoermi@gmx.net> > wrote: > > * Poul-Henning Kamp wrote: > >>You forgot half the "worth-while" part: The compatibility issues. > >> > >>Even something as trivial as "deflate" vs. "gzip" was too hard for > >>some people to get right. > > > > I think people will create an even bigger mess if they're forced to work > > around lack of support for alternative compression schemes in HTTP/2.0. > > -- > > Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de > > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de > > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ > > > >
Received on Tuesday, 21 May 2013 21:37:11 UTC