W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

RE: Comments on draft-chan-http2-stream-dependencies-00

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Fri, 17 Jan 2014 17:39:12 +0000
To: Peter Lepeska <bizzbyster@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532CA81C8@ADELE.crf.canon.fr>
I also much like this proposal. I think that there are interesting things in Martin's suggestion of splitting the PRIORITY field.

Contrary to Martin, I think the ORDERED bit is necessary. Once A <- B is sent, you have two possibilities for adding C inside this relationship:
- Between A and B, resulting in A <- C <- B
- At the same level as B, resulting in A <- B - C

At the same time, I don't like the ORDERED bit to be in a frame flag. So I'd prefer moving it to the PRIORITY field:
- All the information on priorities is in the same location.
- One PRIORITY frame can be used for updating all priorities (both ordered and unordered).

So, when specifying a dependency, we could have:
- P = 0, 1 bit.
- Relative dependency: signed 16 bit int, relative to stream-ID. Backward and forward references are probably desirable (forward references could be useful when updating priorities).
- O: 1 bit, for either ordered or unordered.
- Reserved: 14 bits. (This should be rearranged for easier encoding/decoding).


> -----Original Message-----
> From: Peter Lepeska [mailto:bizzbyster@gmail.com]
> Sent: jeudi 16 janvier 2014 16:57
> To: Amos Jeffries
> Cc: ietf-http-wg@w3.org
> Subject: Re: Comments on draft-chan-http2-stream-dependencies-00
> I don't mean to change the topic, since Amos and Roberto are having a
> good exchange, but I just wanted to endorse the proposal. The benefits
> in terms of page load performance will be big, especially for a
> forward proxy that is able to prioritize across resources from
> different hosts for objects on the same page.
> I like the core ideas of lists of dependent resources representing
> each tab, with resources in the list either ordered or unordered. This
> does expand out into a tree (with unordered dependent objects as
> siblings) but the way the tree is expressed in the draft as a list is
> elegant and simplifying, in my opinion.
> That all said, any amount that we can further simplify this proposal
> without significantly reducing the amount of information the browser
> is providing to upstream servers is great.
> Thanks,
> Peter

Received on Friday, 17 January 2014 17:41:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC