Hi all, I came across the Web Push draft spec recently while researching the current state of the art for pushing “real-time” updates to web applications.
I’ve read the draft spec as it stands and I’m excited about the possibilities. But I’m a little unsure of the intended scope. Is the intention that this should be the primary mechanism for pushing updates while app IS loaded in browser as well as a mechanism for showing “offline” notifications when app is not open? For example, Chrome’s implementation appears to require a visual notification be displayed per message (according to https://developer.mozilla.org/en/docs/Web/API/Push_API). The Firefox implementation according to the same page places some limit on updates that can be received without showing a notification, although "The limit is refreshed each time the site is visited”. I feel I’m trying to read between the lines about whether this proposal is intended to be suitable for general purpose pushing even while app is visible. I note that Facebook’s current implementation supplements their on-page real-time transport which is still based on long-polling XHRs. But then section 7.4 https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html#rfc.section.7.4 talks about an intention to not make apps implement alternative delivery mechanisms, although it’s not clear to me how that would even be possible for the “offline” case which needs this browser support. That seems to imply that it is intended for delivering messages to loaded application tabs too which seems at odds with some of the language above. If it *is* intended to become the single transport for apps to receive push updates even when loaded in tab, I have further questions. However before I dive into deep examples, I wanted to check I was understanding the scope and intended use of this proposal correctly. If anyone has thoughts to share or links to material I can read to find out more than the proposal spec and github issues I’ve seen, I’d be very grateful. Thanks for the work on this - it seems like a great opportunity to bring web app interactivity back on par with native mobile apps without reinventing the message transport each time! Paul
