Re: Push API: not a friend of SPDY

> Keeping a connection established, even using long polling, can increase
> battery usage, network noise and decrease reliability. Allowing the user
> agent to curate such messaging through a single connection, for example an
> operating system provided push service, removes the need for additional
> connections and/or background processes for each website insisting on using
> their own service. This is especially important on mobile devices.

I'd love for you to tell me how QUIC fails to supply this.
 
> The Push API itself does not dictate a transportation mechanism.

Then you MUST mandate the transport mechanism include basic web semantics-
verb, url, headers, body.

Anyone who wants to implement a transport can frame it as they please. Building
a Push that throws away this information when the message is an HTTP message
is something that the lightcone of humanity will hate you for for as long as
it holds together. You really really really can not skimp on this because you
happen to want other circumstances: if you are building a Push spec for the web,
it needs to be able to recieve web-like requsts.

Received on Monday, 27 October 2014 15:42:54 UTC