Re: Push API: not a friend of SPDY

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.

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/

Thanks,
Peter


> That means you need a little bit more well formed an object for Push
> message; one that looks like an HTTP
> request. Might I recommend picking the most harmonious, sensible existing
> spec out there, such that things
> generally work rather than making a brand new IDL for Request?  The
> dead-obvious no-effort-required
> everything-plays-nice developers-don't-laugh-at-you/hate-you-forever
> options would be to implement (as closely
> as permittable) the existing spec for an http request-
> https://fetch.spec.whatwg.org/#request-class
>
>
> I'd point to two previous projects of mine I'd hope Push could help me
> fully deprecate & close the book on-
> Pipe Layer, a bidirectional asynchronous http over http project, doing an
> Opera Unite like thing to reverse
> proxy requests received on the server to the browser)
> https://github.com/rektide/pipe-layer
> Pushchannel, which tracks SPDY Push messages and sends
> X-Associated-Content messages in reply to real resource
> requests, thereby signalling the user-agent as to the existence of the
> pushed resources,
> https://github.com/rektide/pushchannel
>
> Alas, if someone wants to push http traffic to ServiceWorker, they'll ahve
> to pack their messages, often times
> meaning reverse-proxying through a packing service to achieve interop.
> WAMP ho, and that's effing horrible crufty
> ugly dumb and unnecessary.
>
> Alas #2, SPDY's push still doesn't signal and is still all but useless as
> a push mechanism.
>
>
> Whether you will this or you wont, still yours,
> rektide
>
>