- From: <rektide@voodoowarez.com>
- Date: Mon, 27 Oct 2014 10:55:40 -0400
- To: public-webapps@w3.org
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. 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. 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
Received on Monday, 27 October 2014 14:56:05 UTC