Re: Design Issue: GZIP flag on DATA Frames

[Roberto Peon <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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:[e-mail] · http://bjoern.hoehrmann.de
> > Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
> > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
> >
>
>