W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Out-of-order Frames

From: Sam Pullara <spullara@gmail.com>
Date: Sun, 23 Jun 2013 16:20:06 -0700
To: Mike Belshe <mike@belshe.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
Message-ID: <693CBECF-EC24-4329-9D33-D2C8B7A6734E@gmail.com>
This model is pretty easy to do as described without any additional changes to the spec.  I'd like the protocol to support it so it would work with any document format and no application support. Sam   

---Sent from Boxer | http://getboxer.com

On Sun, Jun 23, 2013 at 03:53 PM, Mike Belshe  wrote:It seems to me that a combination of client-side templates and server push could do this with HTTP/2. The client side template is effectively the placeholder you speak of.  The slow-to-compute server resources would be server push streams.  Javascript would glue them together such that receipt of the server push would put the content in place.   One thing we haven't defined (and maybe this is where WHATWG could help) is with Javascript APIs for server push.  For instance, what if the server can push a resource that the client never requests?  Some simple javascript event notifications could really be interesting here.   Mike     On Sun, Jun 23, 2013 at 9:25 AM, Sam Pullara <spullara@gmail.com> wrote:The OBJECT, IFRAME and similar solutions don't work because they aren't in the same document.  Sam   On Jun 22, 2013, at 7:18 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:  > On 23/06/2013 1:45 p.m., Zhong Yu wrote: >> this reminds me another request for out-of-order delivery of an http entity >> >> http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0259.html >> >> (it would be funny though to implement out-of-order frams on top of >> TCP which already deals with out-of-order segments) > > It does sound very similar. But the kfall draft is very close to technically possible. > > The case as presented by Sam the "chunk 3" starting offset is completely unknown to both client *and* server. Take an arbitrary length string, insert a second arbitrary string (length M) into it at a pre-known starting offset (N) and somehow determine the value of N+M before M comes into existence. Not possible until we fix our machines phychic abilities. > > This is a solved problem in markup languages, they use a special tag (OBJECT and IFRAME I referred to earlier, IMG, SCRIPT, VIDEO are others in HTML) in a tree structure which can be adjusted - you should all recognise the DOM. However outside of markup languages multimedia resources are not able to split their content over a tree-like structure without becoming something else. > > Amos > >> >> Zhong Yu >> >> >> On Sat, Jun 22, 2013 at 2:34 PM, Sam Pullara 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 23:20:36 UTC

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