Re: Design Issue: GZIP flag on DATA Frames

Bjoern Hoehrmann <derhoermi@gmx.net> Tue, 21 May 2013 20:47 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0211E8109 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 13:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.932
X-Spam-Level:
X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlSVg1QUIFSE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 13:47:01 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0809F11E8120 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 May 2013 13:47:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UetRt-0006nE-7R for ietf-http-wg-dist@listhub.w3.org; Tue, 21 May 2013 20:46:21 +0000
Resent-Date: Tue, 21 May 2013 20:46:21 +0000
Resent-Message-Id: <E1UetRt-0006nE-7R@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <derhoermi@gmx.net>) id 1UetRi-0006lD-Dk for ietf-http-wg@listhub.w3.org; Tue, 21 May 2013 20:46:10 +0000
Received: from mout.gmx.net ([212.227.17.21]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <derhoermi@gmx.net>) id 1UetRh-0000vM-CM for ietf-http-wg@w3.org; Tue, 21 May 2013 20:46:10 +0000
Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MIjSg-1UcgW72Fiq-002EM9 for <ietf-http-wg@w3.org>; Tue, 21 May 2013 22:45:43 +0200
Received: (qmail invoked by alias); 21 May 2013 20:45:43 -0000
Received: from p5B230E8F.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.14.143] by mail.gmx.net (mp035) with SMTP; 21 May 2013 22:45:43 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18XEagrgsYXNbm1Rv4jjrnhCIqUhi2+n/kS4NrjqS bSRANtH/b5uZzD
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Roland Zink <roland@zinks.de>, ietf-http-wg@w3.org
Date: Tue, 21 May 2013 22:45:43 +0200
Message-ID: <fnlnp8t14lal0uk5suouc2uuk3uk4429dt@hive.bjoern.hoehrmann.de>
References: <CABP7Rbfb92Vxrmxj6fKdt+jpO_Qknq8FRjsu5GZW=17uoi4OFg@mail.gmail.com> <519BAB26.2010501@zinks.de> <4050.1369156663@critter.freebsd.dk>
In-Reply-To: <4050.1369156663@critter.freebsd.dk>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=212.227.17.21; envelope-from=derhoermi@gmx.net; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.840, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UetRh-0000vM-CM f8d9daefcde4c861115d3f060706420a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: GZIP flag on DATA Frames
Archived-At: <http://www.w3.org/mid/fnlnp8t14lal0uk5suouc2uuk3uk4429dt@hive.bjoern.hoehrmann.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18068
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

* Poul-Henning Kamp wrote:
>In message <519BAB26.2010501@zinks.de>, Roland Zink writes:
>
>>This seem to make the introduction of new compression schemes more complex.
>
>And what is the plausibility that any new compression schemes will ever
>make that worth-while ?
>
>It's not nill, but it makes a convincing impression of nill.

There are many existing compression schemes that considerably outperform
Deflate in the compression ratio, some even at comparable consumption in
resources needed for decompression and, less so, compression. Especially
for something like "large JavaScript library" that you would compress
only once, something like http://en.wikipedia.org/wiki/.xz is quite near
a point where I would expect people to call for adoption of a new scheme
(with a filter optimized for such content > 10% better compression seems
very plausible to me). If the protocol cannot support adoption of a new
scheme, there would be pressure to move compression onto a lower level,
think "application/compressed-javascript", and I would rather avoid go-
ing there. My http://bjoern.hoehrmann.de/pngwolf/ was able to strip se-
veral kilobytes off the Google homepage, that already seemed quite worth
it...
-- 
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/