Re: Out-of-order Frames

For anything to be interpreted properly, the receiving side must know what
it is.
HTTP/2's framing layer supports arbitrary numbers of combinations of
'stuff' and metadata to identify what they are.

As has been said earlier (Mike is dead-on) what is missing is an API which
describes how to use this kind of functionality, so ++ what Mike said.
-=R


On Mon, Jun 24, 2013 at 4:57 AM, Michael Sweet <msweet@apple.com> wrote:

> +1 on not complicating HTTP/2.0 with supporting out-of-order fragments.
>
> (I don't buy the transparent-to-application argument - that level of
> optimization will require coordination and is probably better suited to a
> framework that serves up the different resources rather than generating
> out-of-order HTML fragments...)
>
>
> On 2013-06-22, at 5:11 PM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
>
> Sorry, it wasn't clear you wanted this optimization to happen
> transparently without application knowledge, I thought you were trying just
> to achieve a better optimization of some sort.
>
> At this point, most of the conversation is revolving around how the web
> platform uses HTTP in resource loading, and thus the discussion is better
> moved to a web platform list, perhaps whatwg or public-webapps, I dunno. If
> the feeling is that new HTTP semantics would be useful, we can discuss that
> here, but my instinct is that at an HTTP level, it'd be best just to use a
> different resource rather than try to allow out of order response bodies.
> I'm open to what others on this mailing list think though.
>
>
> On Sat, Jun 22, 2013 at 1:47 PM, Sam Pullara <spullara@gmail.com> wrote:
>
>> This seems roughly the same as the JavaScript version but now I need even
>> more coordination with the client application. My intent in adding this to
>> the protocol would be that many applications wouldn't even have to know
>> that this optimization is occurring.
>>
>> Sam
>>
>> On Jun 22, 2013, at 1:41 PM, William Chan (陈智昌) <willchan@chromium.org>
>> wrote:
>>
>> Correct me if I'm wrong, but I think what you're saying is the problem is
>> that chunk 2 is not able to be itself delivered as a set of out of order
>> HTML fragments. The current solution as you described allows for chunk 1 to
>> be immediately flushed by the server and then parsed & rendered by the
>> browser, but then we're stuck with waiting for the server-side template
>> expansion to finish completely before flushing chunk 2, rather than letting
>> chunks of the server generated HTML get inserted into the document out of
>> order.
>>
>> I *think* what you actually want to do is something akin to what a dumb
>> mail reader web app might do. In the inbox view, you have a whole bunch of
>> emails. There's no need to fetch the HTML for all those emails and set them
>> in a single innerHTML command. You can fetch all the emails individually,
>> and build subtrees of DOM nodes as they come in, and then insert into the
>> document as needed.
>>
>> In other words, from HTTP land, if you want to be able to fetch different
>> fragments of a single HTTP resource out of order, then maybe it's best to
>> split that HTTP resource into multiple separate HTTP resources. HTTP
>> doesn't care. At the web platform level, use script to re-assemble these
>> different resources together into the actual document. This requires no
>> changes in HTTP nor the web platform.
>>
>>
>> On Sat, Jun 22, 2013 at 1:15 PM, Sam Pullara <spullara@gmail.com> wrote:
>>
>>> I'm all for brainstorming. The current solution works basically like
>>> this:
>>>
>>> Chunk 1 (sent immediately):
>>>
>>> <html>
>>> <body>
>>> <div id="1"></div>
>>> </body>
>>> </html>
>>>
>>> Chunk 2 (calculated completed and sent later):
>>> <script>document.getElementById("1").innerHTML = "<span>Hi William
>>> Chan!</span>";</script>
>>>
>>> Even if the browser can do no work before receiving all the data it is
>>> still better because the bytes are sent sooner than they normally would be
>>> sent. However, I think that the browser would be able to parse complete DOM
>>> elements in the fragments to do even more work before the page has been
>>> completely rendered on the server. The contract with the browser might be
>>> that delayed frames must be complete elements like in the example. Rather
>>> than out of order frames we might have some way of specifying a named frame
>>> to be replaced later. There are a number of possible implementations.
>>>
>>> Sam
>>>
>>>
>>>
>>> On Jun 22, 2013, at 1:06 PM, William Chan (陈智昌) <willchan@chromium.org>
>>> wrote:
>>>
>>> OK, it sounds like you want to be able to send out of order byte
>>> sequences for a single resource, by sending out of order frames for the
>>> same HTTP/2 stream. This is not possible without changing HTTP semantics,
>>> and HTTP/2 is primarily only working on improving the mapping of HTTP
>>> message semantics onto a connection.
>>>
>>> Btw, why would you want to do this? The browser rendering engine cannot
>>> do anything with just frame 1 and frame 3 anyway. HTML parsing requires
>>> in-order parsing of the document.
>>>
>>> Stepping back, I still don't fully understand the problem with the
>>> existing solution that relies on script to dynamically fill in the DOM
>>> nodes as they become available. Can you clarify what you are hoping HTTP2
>>> can do that would be better? Maybe there's a better solution here?
>>>
>>>
>>> On Sat, Jun 22, 2013 at 12:52 PM, Sam Pullara <spullara@gmail.com>wrote:
>>>
>>>> Sorry, let me give a concrete example. You have an HTML page that
>>>> ultimately needs to look like:
>>>>
>>>> <html>
>>>> <body>
>>>> <span>Hi William Chan!</span>
>>>> </body>
>>>> </html>
>>>>
>>>> In order for me to figure out the contents of the span I need to check
>>>> an authentication database and do some kind of hard computation that might
>>>> take several 100 ms. What I am proposing is that you could send 3 "frames"
>>>> or "chunks" or whatever is the final form like this:
>>>>
>>>> Stream:
>>>>  Frame 1:
>>>>  <html>
>>>>  <body>
>>>>  Frame 3:
>>>>  </body>
>>>>  </html>
>>>> … some time later …
>>>>  Frame 2:
>>>>  <span>Hi William Chan!</span>
>>>>
>>>> The client then reconstructs the final document, optionally doing some
>>>> processing on the parts of the document it received before completion. I'm
>>>> pretty sure the protocol doesn't allow out of order frames within a stream
>>>> right now. In section 3.4 it states:
>>>>
>>>>    o  The order in which frames are sent within a stream is significant.
>>>>       Recipients are required to process frames in the order they are
>>>>       received.
>>>>
>>>> Sam
>>>>
>>>> On Jun 22, 2013, at 12:47 PM, William Chan (陈智昌) <willchan@chromium.org>
>>>> wrote:
>>>>
>>>> I'm having difficulty fully understanding the problem and the proposal.
>>>> Can you clarify?
>>>>
>>>> * What do you mean by "frame"? Do you mean frames in the HTTP/2 framing
>>>> layer? Frames in the framing layer can appear in any order (subject to a
>>>> few rules), so I don't know what out-of-order frames means. Or do you mean
>>>> like video frames?
>>>> * If you meant video frames, then if you separate the video into
>>>> multiple resources, there's no reason the resources can't be sent "out of
>>>> order", since at the HTTP level there's no concept of order among resources.
>>>>
>>>>
>>>> On Sat, Jun 22, 2013 at 12:34 PM, Sam Pullara <spullara@gmail.com>wrote:
>>>>
>>>>> Commonly in dynamically generated websites there are sections of
>>>>> content that are static and parts that are calculated on a per request
>>>>> basis. The current best practice for accelerating the delivery of a page
>>>>> like this involves leaving identifiable DOM elements where the dynamic
>>>>> content would appear, flushing the entire static page, and then flushing
>>>>> JavaScript script nodes as calculations complete (e.g. Facebook's BigPipe
>>>>> and deferred rendering in mustache.java). This practice only works for HTML
>>>>> pages (with JavaScript enabled) and offers no acceleration for other types
>>>>> of content delivered over HTTP.
>>>>>
>>>>> One possible solution to this problem would be to allow for
>>>>> out-of-order frames where the static frames are sent as quickly as the
>>>>> connection allows and dynamically generated frames are then sent later as
>>>>> they become available on the server. We would likely not want to enable
>>>>> this in general and would likely need to negotiate this behavior between
>>>>> client and server. Looking at the spec, frames might not be the right place
>>>>> but something on top of frames because of the size limitations.
>>>>>
>>>>> Has something like this been discussed before? Would this be the right
>>>>> mechanism or are there better ways to do it?
>>>>>
>>>>> Thanks,
>>>>> Sam
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>

Received on Monday, 24 June 2013 21:36:19 UTC