Re: Web Push API intended scope

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 04:38:49 UTC