Re: Push API: not a friend of SPDY

On Mon, Oct 27, 2014 at 03:12:05PM +0000, Peter Beverloo wrote:
> On Mon, Oct 27, 2014 at 2:55 PM, <rektide@voodoowarez.com> wrote:
> 
> > Hello. I heard Push is finally in consideration, and having a link put in
> > front of me finally got around to
> > looking- while I'm overjoyed to think the user-agent might expose
> > endpoints, this implementation is however not
> > a friend to SPDY (nor a friend to HTTP); comments, 2:
> >
> >
> > SPDY has push. I'd like to see a Push API that can inform the
> > serviceworker of data pushed via SPDY push. No
> > endpoint registration is required! It's a capability which already exists
> > in every SPDY connection, for which
> > the browser has no corresponding ability to detect the Push. Push already
> > exists, we just don't signal it.
> >
> > Exposing an HTTP server that works as an ingestion endpoint is awesome,
> > it's far more flexible, and far less
> > tightly coupled. This absolutely needs to be another, available form of
> > Push for the user-agent; 100%.
> >
> > But I'd also like to be able to use the push channel that already exists.
> > Please allow SPDY Push to work as a
> > transport in to Push API.
> >
> 
> It sounds like you're searching for something like
> http://dev.w3.org/html5/eventsource/, but with event delivery to a Service
> Worker.
> 
> 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.
> 
> The Push API itself does not dictate a transportation mechanism.

EventSource is close, except it too (like Push) is a higher level protocol on 
top of HTTP.  In this modern new awesome world with great tech, we can actually
just Push without having to build a higher level protocol- all we need is for 
the browser to be signalled for what has already happened. So, like EventSource,
except entirely free and requiring no new protocols or systems of exchange 
what-so-ever and being totally baked in already.

EventSource is also not web. It's just a stupid text resource. I'd like to
expose the actual Push mechanism actually underlying the web everyone is already
using.
 
> Second, why is no header information available in the Push message? Making
> > the client a server but then putting
> > masking tape over the envelope is... un-ethical, brutal, mean, dispirited,
> > breaks things heniously. People are
> > going to send HTTP traffic to it anyways, they're just going to have to
> > wrap/pack unwrap/unpack it, possibly
> > through someone's reverse proxy. For frell sake, expose the headers. The
> > data is going to get there, this is
> > what _is_ going to happen, don't make it a sin of different horrible ways
> > of munging it together.
> >
> 
> User agents are free to choose their own message transportation mechanism.
> As a developer, you send a message to the push service (e.g. Google Cloud
> Messaging) rather than to the user, which then forwards it accordingly.
> Many of such services dictate a certain message format or header format.
> 
> There is an ongoing effort to standardize a server-to-server protocol to
> enable delivery of more inclusive messages. I encourage you to participate
> if this yields your interest. (It is based on HTTP/2.)
>     http://datatracker.ietf.org/wg/webpush/documents/

This looks exactly like my Pushchannel project. Which I want to deprecate and
not implement, because SPDY and QUIC have Push and all we need is an API for
generic notification of asserted resources. Aka Push.

It's absurd that we'd build a spec for Push based exclusively around _old_
ancient paths for HTTP that willfully ignores the actual underlying transport's
capabilities to actually push.

Received on Monday, 27 October 2014 15:36:49 UTC