- From: Chad Austin <caustin@gmail.com>
- Date: Wed, 1 Oct 2014 18:12:36 -0700
- To: ietf-http-wg@w3.org
- Message-ID: <CA+dRvWhbY8DQFy+4RycJPwLoHa4ictZR90FENRKE6Y85PDZPHQ@mail.gmail.com>
Hi, I am reading the HTTP 2.0 draft, and I wonder whether HTTP 2.0 supports implementing simple stream priorities like SPDY does. Our use case is documented in detail at http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/ , but I will summarize here. We have a whole pile of 3D assets that we need to retrieve from various URLs and load into WebGL. Some of them are higher-priority than others. None of them depend on any other. For example, we may want to prioritize resources closer to the camera. We definitely want to prioritize meshes and low-resolution textures over high-resolution textures and animation files. Ideally, our application would immediately issue ALL requests and let the browser's network stack (and HTTP/SPDY/HTTP2 backend) efficiently utilize the socket(s) and bandwidth to transfer high-priority assets before low-priority assets. However, if there is available bandwidth, we would benefit from receiving low-priority assets in the meantime. We would benefit from a large number of priority bits, but could make it work with as low as 3 bits. (2 bits would be too few.) How do I map that use case to HTTP 2.0's dependency graph? At first blush, it seems hard: I'd have to define a stream per priority level, and set dependencies such that all low-priority streams depend on high-priority streams? And if a high-priority stream finishes, then reset the dependency to another high-priority stream? -- Chad Austin http://chadaustin.me
Received on Thursday, 2 October 2014 01:13:04 UTC