- 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>
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). Hervé. > -----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