Paul, just for you: https://github.com/w3c/push-api/issues/179
On 13 January 2016 at 19:17, Paul Banks <ba...@banksco.de> wrote: > Hi Martin, > > Thanks for the clarification. This makes sense to me. > > Perhaps I missed it - I'll read again closely but I wonder if that intent > could be expressed in those clear terms in the draft text? I don't recall > seeing "infrequent" messaging mentioned at all for example. > > Thanks again. > > Paul > > > >> On 13 Jan 2016, at 04:38, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> Hi Paul, >> >> The Push API is intended for infrequent messages. If you have a page >> open to site, it might still be suitable to rely on push for messages >> that are infrequent or unpredictable. However, if you are actively >> communicating with your site, it is best to use more direct means of >> sending messages, such as HTTPS. Direct communications is both faster >> and more efficient if you are already actively talking to a server. >> >> The intent of the text you cite about building alternative delivery >> mechanisms, is intended to discourage application developers from >> building a long-running communications channel solely for the purpose >> of receiving low-rate, or low-probability messages. Many web >> applications do this today and it has a terrible effect on device >> battery life. >> >> --Martin >> >>> On 12 January 2016 at 09:08, Paul Banks <ba...@banksco.de> wrote: >>> 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 >>>
