Re: Reference set in HPACK

["Eric J. Bowman" <[e-mail]>]

RUELLAN Herve wrote:
>
> > Poor caching consequences of *mis-*using inlining. I still don't see
> > how it applies to how I, or anyone I know, uses inlining. I also
> > disagree that an efficient push mechanism will stop me from inlining
> > all the little images which make up the "chrome" of a site design
> > (which surely don't need to be first-order resources).
> > 
> > Say for instance, I have several "slivers" of gradient or whatever
> > that I'm going to repeat-x repeat-y. Inlining these into one image
> > has no downside vis-a-vis caching, plus the upside that it can
> > shave maybe 80% of the bytes incurred by image-format overhead. How
> > would using push to send them individually, benefit me in any way?
> 
> I think you are using different definitions of inlining. Your view of
> inlining is to pack several images into one big image. Roberto's view
> is to encode these images inside the html document (this is more
> relevant for javascript and css than for images).
> 

Inlining can also refer to embedding images in CSS as data. Thanks for
clarifying, I was wondering if we were talking around each other.

>
> With one large html document including the images, you don't need to
> request these images after receiving the html, but you can't cache
> them for the next html document.
> 

OK, that makes sense, thanks.

-Eric