Re: In defense of PUSH

On September 1, 2018 2:19:12 AM GMT+08:00, Matthew Phillips <matthew@bitovi.com> wrote:

>And with new streaming APIs in the browser, it can stay connected to
>this
>stream for the lifetime of the application, receiving new messages as
>they
>come. This prevents needing to use WebSockets and the complexity they
>bring.

Ws is nice and simple on the JS side... it's only complicated on most servers because it's treated as an alien bolted-on protocol.

Do you really need "new streaming apis in the browser" or isn't it "native h2 ws" that can expose asynchronous messages using h2 streams, PUSHed or not, as the transport?

When ws-over-h2 was discussed I suggested supporting PUSH, but the consensus wanting to see it implemented wouldn't support the extra complexity, leaving it for a putative future native ws replacement.

With h1 ws it's expensive for the client to set up a new connection and tls back to the server after it received the script telling it to do so, ws-over-h2 improves it, but native h2 ws using PUSH could be right there already with the first message as soon as the script realized it wanted it.  At the cost of the complexity of teaching the server that fetching xxx implies pushing yyy.

Although you seem to write off ws, its async atomic message focus and apis seem to match what you're trying to do (and have a story for h1 compatibility).   If you're not aware of it, the latest version is here

https://datatracker.ietf.org/doc/draft-ietf-httpbis-h2-websockets/

>In a slightly more complex example, my company has been envisioning an
>alternative to HTML streaming that utilizes H2 PUSH. When I say HTML
>streaming I am talking about the technique of sending HTML in chunks,
>as
>database results come in, until the fully page is sent out. One problem
>with HTML streaming is that the top of the page isn't always ready
>before
>parts further down.

A lot of applications want atomic JSON messages rather than chunks of html, ws semantics in JS handle this well.  Browsers seem to want to get to the loaded event triggered by definitively having received all the pieces so the layout is finalized, the 'dribbling html stream' delays that indefinitely.

>H2 PUSH is critical for doing this. Without the ability to push this
>mutation stream, it doesn't have as much of an advantage over using

I think it's fair to say you want ws style atomic messages, if you could get them via h2 PUSH that'd be ideal.  The neccessity for ongoing, async messages are the real issue, PUSH is only a - desirable - optimization.

-Andy

Received on Friday, 31 August 2018 19:41:27 UTC