Re: CBOR Tutorial

Hi all,

It seems to me that there is at least one good reason to avoid package-level compression when the package isn’t being streamed: Not all receiving clients will use all resources (e.g. due to CSS media queries). Thus, time and effort would be unnecessarily put into compression only to cause more unnecessary decompression later. Resource-level compression avoids these inefficiencies.

Regards,
Dave
-- 
David Hyland-Wood
http://about.me/david_wood


On 1 February 2018 at 03:34:47, Jeffrey Yasskin (jyasskin@google.com) wrote:

On Wed, Jan 31, 2018 at 6:47 AM Garth Conboy <garth@google.com> wrote:


On Wed, Jan 31, 2018 at 6:36 AM, Baldur Bjarnason <baldur@rebus.foundation> wrote:
If you are storing full requests and responses then surely individual entries can be compressed using gzip encoding much in the same way that most normal requests are compressed?

If we have the full range of normal HTTP headers available then I’d be very surprised if, on average, a web package had any entry that wasn’t gzipped individually.

Yep -- seems that could/should be the case -- like verification.

I'm anticipating 3 aspects of package/bundle/PWP(/WebZip? ah, naming) compression:

1) When downloading a package, it can be compressed as a whole. It should not be stored this way, because that loses random access to internal resources.
2) As Baldur suggests, individual resources can be compressed with the format identified with their Transfer-Encoding headers. When the Brotli folks get around to proposing shared dictionaries, I expect they'll define a header that will also let this kind of resource be compressed with a dictionary that's provided elsewhere in the bundle.
3) The request and response headers should also be compressed using a shared dictionary. This isn't designed yet, and depending on the average size of response payloads might not matter for PWP uses, but it's going to matter for bundling ES6 modules, so it'll get done eventually.

HTH,
Jeffrey