WebApps-ACTION-755: Solve the rest of the problems related to robust targeting of changing documents.
WebApps-ACTION-755: Solve the rest of the problems related to robust targeting of changing documents. http://www.w3.org/2008/webapps/track/actions/755 Assigned to: Robin Berjon
[pointerlock] Oct 2014 Pointer Lock Status
Implementation status: (Chrome and IE have changed status since April) Chrome: Implemented without prefix, in stable version. Firefox: Implemented with prefix, in stable version. IE: Implementation active. Issue: http://connect.microsoft.com/IE/feedback/details/793718/ie11-feature-request-support-for-pointer-lock-api Safari: No implementation progress known. Opera: No implementation progress known. Test suite (has not changed since April): Two basic tests exist: http://w3c-test.org/pointerlock/constructor.html http://w3c-test.org/pointerlock/idlharness.html After unprefixing, tests fail partially in Chrome. Firefox fails due to prefixing. Plan to "complete" test suite: - Implementations need to start using W3C tests that exist - More implementations need to support unprefixed pointer lock. - Chromium issue: https://code.google.com/p/chromium/issues/detail?id=359740 - More tests are needed. - I sense little prioritization from Chrome or Mozilla organizations to do this soon. IE with a new implementation may use the opportunity to create more testharness.js tests. Specification discussion: Previous extension discussion has been given a term "Pointer Clip" and notes added to https://www.w3.org/wiki/Webapps/PointerLockFeatures
WebApps-ACTION-754: Work with doug and chaals re fuzzy pointers stuff for web annotations wg
WebApps-ACTION-754: Work with doug and chaals re fuzzy pointers stuff for web annotations wg http://www.w3.org/2008/webapps/track/actions/754 Assigned to: Frederick Hirsch
WebApps-ACTION-753: Find an msdn page that describes this
WebApps-ACTION-753: Find an msdn page that describes this http://www.w3.org/2008/webapps/track/actions/753 Assigned to: Travis Leithead
Re: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note
On Mon, Oct 27, 2014 at 10:26 PM, Travis Leithead wrote: >>When are we going to see the hit testing part of mouse events >>defined? What draft will integrate with the event loop model and >>deal with relative ordering of the events and which happen as part >>of the same task and which as part of a distinct task, etc? > > Scheduled for inclusion in DOM Level 3 Events (Bug 25927) > > ...and other bugs yet to be fixed. That's great to hear. If we are changing the scope so drastically from what was originally envisioned for that document, why not use a new name? "DOM Level 3 Events" is the last document out there that uses DOM in the name while it's not actually defining DOM. Instead, it defines a bunch of user interaction events. -- https://annevankesteren.nl/
WebApps-ACTION-752: Do edits on file system spec
WebApps-ACTION-752: Do edits on file system spec http://www.w3.org/2008/webapps/track/actions/752 Assigned to: Arun Ranganathan
WebApps-ACTION-751: Followup with cameron re pr 27 and the web idl test suite
WebApps-ACTION-751: Followup with cameron re pr 27 and the web idl test suite http://www.w3.org/2008/webapps/track/actions/751 Assigned to: Yves Lafon
RE: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note
>From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf >Of Anne van Kesteren >On Mon, Oct 27, 2014 at 8:06 PM, Travis Leithead > wrote: >> We should have a plan for the bugzilla component (there are some good >> "future" bugs logged there). Would the bugzilla component stay open? Would >> >> we need to move the bugs to D3E otherwise? (We can mark them future, or >> something to distinguish them.) > >What's the context for this new plan? Sorry, this came out of comments from Marcos and others that having UI Events on WebApps's PubStatus (and in Google Search results) along with DOM Level 3 Events was confusing--e.g., which is the spec to be looking at? It turns out that the current UI Events spec has very little in it at the moment (we've back-ported most of its content into DOM Level 3 Events), and is now understood to be a home for future "UI Events" features (after wrapping up DOM Level 3 Events). So, the suggestion was that we officially stop working on UI Events (as a current deliverable) and potentially re-start it later when we're ready. This should alleviate the confusion. This lead to my questions above. >What draft is going to define event constructors? DOM Level 3 Events (already done) >When are we going to see the hit testing part of mouse events >defined? What draft will integrate with the event loop model and >deal with relative ordering of the events and which happen as part >of the same task and which as part of a distinct task, etc? Scheduled for inclusion in DOM Level 3 Events (Bug 25927) ...and other bugs yet to be fixed.
WebApps-ACTION-750: Deleted the uc in file api that starts with "data should be able to be stored ..."
WebApps-ACTION-750: Deleted the uc in file api that starts with "data should be able to be stored ..." http://www.w3.org/2008/webapps/track/actions/750 Assigned to: Arun Ranganathan
WebApps-ACTION-749: Start a cfc to publish file api lcwd
WebApps-ACTION-749: Start a cfc to publish file api lcwd http://www.w3.org/2008/webapps/track/actions/749 Assigned to: Arthur Barstow
Re: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note
On Mon, Oct 27, 2014 at 8:06 PM, Travis Leithead wrote: > We should have a plan for the bugzilla component (there are some good > "future" bugs logged there). Would the bugzilla component stay open? Would we > need to move the bugs to D3E otherwise? (We can mark them future, or > something to distinguish them.) What's the context for this new plan? What draft is going to define event constructors? When are we going to see the hit testing part of mouse events defined? What draft will integrate with the event loop model and deal with relative ordering of the events and which happen as part of the same task and which as part of a distinct task, etc? -- https://annevankesteren.nl/
WebApps-ACTION-748: Mark file list as feature @ risk
WebApps-ACTION-748: Mark file list as feature @ risk http://www.w3.org/2008/webapps/track/actions/748 Assigned to: Arun Ranganathan
RE: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note
We should have a plan for the bugzilla component (there are some good "future" bugs logged there). Would the bugzilla component stay open? Would we need to move the bugs to D3E otherwise? (We can mark them future, or something to distinguish them.) -Original Message- From: Web Applications Working Group Issue Tracker [mailto:sysbot+trac...@w3.org] Sent: Monday, October 27, 2014 9:26 AM To: public-webapps@w3.org Subject: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note http://www.w3.org/2008/webapps/track/actions/734 Assigned to: Arthur Barstow
WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note
WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note http://www.w3.org/2008/webapps/track/actions/747 Assigned to: Arthur Barstow
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, 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
[Bug 27179] [Custom]: The timing at which callbacks are invoked need to be defined more precisely
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27179 Dimitri Glazkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dimitri Glazkov --- *** This bug has been marked as a duplicate of bug 24579 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27179] New: [Custom]: The timing at which callbacks are invoked need to be defined more precisely
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27179 Bug ID: 27179 Summary: [Custom]: The timing at which callbacks are invoked need to be defined more precisely Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 http://www.w3.org/TR/custom-elements/#enqueuing-and-invoking-callbacks has the following normative text for when custom elements' callbacks are called: ``` Any time a script calls a method, reads or sets a property that is implemented by the user agent, the following actions must occur: When transitioning from script to the user agent code, push a new element queue to the processing stack When transitioning back from the user agent code to script, pop the element queue from the processing stack and invoke callbacks in that queue. ``` This needs to be more precisely defined in Web IDL, and the custom elements spec should refer to that. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Push API change for permissions UX
On Sat, Oct 25, 2014 at 11:42 PM, Jake Archibald wrote: > This discussion is about how often push may be processed silently (without > showing a notification), not if a push notification may *only* show a > notification. Ok. I think this comes back to the old problem of that different UAs have different UIs and that it's hard to create a single spec to cover them all. The use case sounds reasonable to me, but I'm not sure if mozilla has plans to implement anything similar. I'll defer to other people working on push. / Jonas
WebApps-ACTION-745: Followup with simon re running the web workers tests
WebApps-ACTION-745: Followup with simon re running the web workers tests http://www.w3.org/2008/webapps/track/actions/745 Assigned to: Arthur Barstow
WebApps-ACTION-746: Determine kris' availability to work on the web messaging and web sockets implemenation reports
WebApps-ACTION-746: Determine kris' availability to work on the web messaging and web sockets implemenation reports http://www.w3.org/2008/webapps/track/actions/746 Assigned to: Adrian Bateman
WebApps-ACTION-743: Try to find someone to help yves, cam and boris on web idl v1
WebApps-ACTION-743: Try to find someone to help yves, cam and boris on web idl v1 http://www.w3.org/2008/webapps/track/actions/743 Assigned to: Charles McCathie Nevile
[Bug 25090] Use document's encoding for url query encoding in XHR open()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25090 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Anne --- Well, why don't you bring this up at the next Blink F2F or some such? Maybe they're willing to take a stance here one way or another and everyone else can follow. -- You are receiving this mail because: You are on the CC list for the bug.
WebApps-ACTION-744: Work on moving web idl v1 to rec
WebApps-ACTION-744: Work on moving web idl v1 to rec http://www.w3.org/2008/webapps/track/actions/744 Assigned to: Yves Lafon
WebApps-ACTION-742: Re sse test results, followup on the timeouts with the 2 test facilitators
WebApps-ACTION-742: Re sse test results, followup on the timeouts with the 2 test facilitators http://www.w3.org/2008/webapps/track/actions/742 Assigned to: Arthur Barstow
WebApps-ACTION-741: Ask cjk interest group and others about ime (use cases, tests, etc.)
WebApps-ACTION-741: Ask cjk interest group and others about ime (use cases, tests, etc.) http://www.w3.org/2008/webapps/track/actions/741 Assigned to: Charles McCathie Nevile
WebApps-ACTION-740: Issue a call for test facilitator for ime spec
WebApps-ACTION-740: Issue a call for test facilitator for ime spec http://www.w3.org/2008/webapps/track/actions/740 Assigned to: Arthur Barstow
WebApps-ACTION-739: Start a cfc to publish a proposed recommendation of idb
WebApps-ACTION-739: Start a cfc to publish a proposed recommendation of idb http://www.w3.org/2008/webapps/track/actions/739 Assigned to: Arthur Barstow
WebApps-ACTION-738: Start a cfc to publish a "gutted" wg note of the fullscreen api
WebApps-ACTION-738: Start a cfc to publish a "gutted" wg note of the fullscreen api http://www.w3.org/2008/webapps/track/actions/738 Assigned to: Arthur Barstow
WebApps-ACTION-737: Create a new bugzilla component for inner text
WebApps-ACTION-737: Create a new bugzilla component for inner text http://www.w3.org/2008/webapps/track/actions/737 Assigned to: Arthur Barstow
Re: Push API: not a friend of SPDY
On 27 October 2014 08:42, 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.
WebApps-ACTION-736: Work with adrian to find a replacement tc for alex and d3e
WebApps-ACTION-736: Work with adrian to find a replacement tc for alex and d3e http://www.w3.org/2008/webapps/track/actions/736 Assigned to: Arthur Barstow
WebApps-ACTION-735: Check that the d3e tests are in gh or mercurial, and if needed fix
WebApps-ACTION-735: Check that the d3e tests are in gh or mercurial, and if needed fix http://www.w3.org/2008/webapps/track/actions/735 Assigned to: Travis Leithead
WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note
WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note http://www.w3.org/2008/webapps/track/actions/734 Assigned to: Arthur Barstow
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 Mon, Oct 27, 2014 at 03:12:05PM +, Peter Beverloo wrote: > On Mon, Oct 27, 2014 at 2:55 PM, 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.
Re: Push API change for permissions UX
Example https://www.youtube.com/watch?v=0i7YdSEQI1w - Twitter shows notifications without caching, creating a poor offline (or poor connectivity) experience. You can actually be left with less information after tapping the notification than before. On 26 October 2014 06:42, Jake Archibald wrote: > This discussion is about how often push may be processed silently (without > showing a notification), not if a push notification may *only* show a > notification. > > The latter was shown to be insufficient in the other thread. > On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore > wrote: > >> I think it might make sense to ask for permission to display > >> notifications/UI at the same time as you ask for permission to "run in > the > >> background". > > > > I hope the above explains why we believe that while some sites may want > to > > ask for both permissions, they should be able to say to the user "Hey, I > > want to send you notifications", without saying "Hey, I want to run in > the > > background whenever I want for any reason". > > I suggest that if we attempt to solve this use case, that we do it by > adding the ability to send push messages that directly create a > notification, without waking up a SW. > > There's recently been a separate thread about that. > > / Jonas > >
Re: Push API: not a friend of SPDY
On Mon, Oct 27, 2014 at 2:55 PM, 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 > >
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
