Re: Web Push API intended scope

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.thomson@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 <banks@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
>>

Received on Wednesday, 13 January 2016 08:17:48 UTC