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 >>
