Re: Out-of-order Frames

On 23/06/2013 8:15 a.m., Sam Pullara 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.

I completely agree. This current style of coding which relies completely 
on JavaScript execution is rather nasty.

When I learned HTML there were these things called OBJECT tags which we 
were taught to use for this exact use-case...

example.html would look like this:
<html><body>
<object type="text/html" data="/name.cgi">Guest - Please <button 
name="login" onclick="/login.cgi">Log In</button></object>
</body></html>

name.cgi would produce this part:
<div>Hi Sam,</div>

and login.cgi would do anything required to perform login before either 
returning.


The UX used to be seamless, work on all the HTML3 or HTML4 compliant 
browsers and the page rendering time was at least twice as fast as it is 
when waiting for JS engines to load, parse, execute *then* do the extra 
downloads. The above still works today, although in HTML5 the things 
seem to have taken a u-turn towards complexity with IFRAME replacing the 
earlier nested OBJECT.


IMHO, your requested protocol change is not necessary - it is just 
another complication of the protocol to resolve a disagreement at the 
markup and resource format (webapp?) layer. Which seems to already have 
a host of useful solutions. Not all resources are equal in which 
solution they can use any more than they are equal in resource 
consumption to output.

Amos

>
> Sam
>
>
>
>
> On Jun 22, 2013, at 1:06 PM, William Chan (陈智昌) 
> <willchan@chromium.org <mailto: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 
>> <mailto: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 <mailto: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 <mailto: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
>>>
>>>
>>>
>>
>>
>

Received on Sunday, 23 June 2013 02:01:31 UTC