Re: Push API: not a friend of SPDY
Follow-up: there was an issue for meta-data already on the Github. https://github.com/w3c/push-api/issues/81 Please, think of the resources and be webby to one another. Cheerio, rektide On Mon, Oct 27, 2014 at 10:55:40AM -0400, rekt...@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. 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
Re: Push API: not a friend of SPDY
On Mon, Oct 27, 2014 at 11:58:03PM -0700, Costin Manolache wrote: On Mon, Oct 27, 2014 at 11:20 AM, rekt...@voodoowarez.com wrote: On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote: On 27 October 2014 08:42, rekt...@voodoowarez.com wrote: 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. That's a pretty strong assertion. Can you provide any justification for that? Any metadata you might want to carry can always be placed in a payload after all. Not really - the payload is supposed to be end-to-end encrypted, so the push server can't place anything in the payload. The push server may want to indicate at least the (authenticated) source of the message (unless it operates as an open-relay :-). AFAIK http://tools.ietf.org/html/draft-thomson-webpush-http2-00 uses HTTP/2 for the UA to push server - which obviously includes the usual headers. So not really sure what this thread is about and why the headers would be just dropped in the JS API, I am assuming they will show up when a clean way to expose them is found ? This is my concern. I'm concerned that Push API leaves no standard JS API for pushed resources to be seen as resources. Unless Push API has an affordance for exchanging resources, it becomes very very hard to use. For example, a scenario: meatspace, a webapp where a short movie clip and text is sent to everyone looking at a web page. A client would need to get a text message and a video message pushed to it. How does the client know the content-type of the movie clip sent to them? At present, I see no means for the Push API to afford this information, even though it was sent to the WebPush server. Hence my assertion: 1. Headers and method should be optional fields on the Push event (relaying the vital web information- content-type c) 2. For consistency data should be renamed body. Thank you very much for writing Costin. I greatly appreciate you stating your confusion, and doubly appreciate you asking questions.
Push API: not a friend of SPDY
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
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.
Re: Push API: not a friend of SPDY
On 27 October 2014 08:42, rekt...@voodoowarez.com wrote: 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. That's a pretty strong assertion. Can you provide any justification for that? Any metadata you might want to carry can always be placed in a payload after all.
Re: Push API: not a friend of SPDY
On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote: On 27 October 2014 08:42, rekt...@voodoowarez.com wrote: 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. That's a pretty strong assertion. Can you provide any justification for that? Any metadata you might want to carry can always be placed in a payload after all. I've already discussed packing into the payload: we have specs such as WAMP which we can use to pack CALL/RESPONSE messages to a URL into JSON. We could simply send a valid HTTP response. But how do we get the content-type to know what kind of packing the message has if we start to communicate with an unknown endpoint? This is a spec being built for transfering resources to a user agent. This is undeniable. But the group right now for whatever reason is focused on sending only opaque resources - no content-type, no addressability of the resource being pushed. User agents already receive resources, and when they do those resources are so called because: * They have a URL identifying the resource * They have meta-data describing the conditions of transfer of that resources. You are the WWW consortium: you should be working to send resourceful resources to the user -agent. You shouldn't just cram some new telnet protocol v3.0 (websockets 2.0) into a brand new API in a manner completely decoupled from how the rest of the web works. This work is being done in conjunction with ServiceWorkers, which themselves are 100.000% about resources- yet you are proposing a means of communicating with them which can not talk resourcefully. Why should ServiceWorkers have to fill itself with data passed out of band, via means that Push is itself incapable of equivocating? That seems nonsensical. I would like the working group to move from pushing messages to pushing resources. We are here (the w3) because of resources. This spec should move to push resources. Please respect what is fundamental to the web, and bring Push design more in line with: http://www.w3.org/DesignIssues/Principles.html I'd also point out your charter, which says: The Web Applications Working Group should adopt, refine and when needed, extend, existing practices where possible. Such as the practice of transmitting resources. Given a couple days of research, I'd also love to point out how using Resources over opaque messages fulfils this line in in your charter- Furthermore, the Web Applications Working Group deliverables must address issues of accessibility, device independence, internationalization, mobility, privacy, and security. My recommendation is for this spec to define optional (perhaps recommended) url, and headers fields on Push message (domstring/dict), and to rename data to body, establishing a convention for resourceful exchange to happen. If these two steps are done, in addition to fulfilling your charter, I believe the Provide Channel step in http://tools.ietf.org/html/draft-thomson-webpush-http2-00#section-2 could be nothing more than a reverse SPDY proxy, which would simplify implementation. As it stands, it's unclear (to me) what exactly the provided channel constitutes. Last an apology; I realize I'm probably not well enough in line with the calm attitude of a working group. Mr Domenic Denicola confirms that in IRC by saying, i don't really want to get involved in that conversation; the OP's vulgar attitude makes me think engaging will not be constructive. And his words express my own thoughts. I feel enormous passions about this topic, and I have much anxiety about presenting what to me is an obvious, clear, simple fix with a direct clear and obvious mandate, one which will Move The Web Forward, which pushes us towards The Web We Want, which arrives us at a resourceful/web future, and I see such a massive colossal distance that I feel I will never come anywhere near close to cracking, a distance I cannot fathom; and this, at least, what I come as, is honest and not overly plucked. But I am sorry for tracking personal noise into this channel, and I am sorry for the additional burden I levy by not having the experience, confidence or connections to better massage my mess of feelings into a manner more appropriate for this working group's direct consumption. Thank you for attending. I've To:'d two people who I'd appeal to for help maintaining a web built of resources, although I'm far from sure they'll agree with the connection I'm trying to suggest between Push and opaque/web messaging/resouces. regards, yours, rektide
