Re: Web Push API intended scope

Thanks for that Costin although I'm not sure if you are advocating for use of Web Push in this role or stating that there would be benefits if it was designed to support this workload better. 

The biggest case where is see a limit in specified functionality is for in-page updates like updating a comment thread on a particular item as new comments are added. In this case the updates might be considered "infrequent" but you don't really want context-free notifications for that thread when you aren't actually looking at the relevant page. 

Web Push seems to be aimed at only notifications that should alert user in a "context free" way whether the app is open in a tab or not. By context free I mean things that are relevant to that user in general (e.g. new message for you) rather than relevant to a particular page or view that might be visible currently. The latter could possibly be built on web push but the cost of dynamic/short lived subscription management seems to make it infeasible in general.

I think it's probably right to keep this standard focuses on that one task, it's just a shame that many sites even with only modest/infrequent messaging needs will likely still need to implement their own streaming/polling/websocket infrastructure to support in-page use cases as well as web push services for background notifications. 

Just my thoughts - I'm sure the authors have spent a lot more time thinking about this than I have!

Thanks for the discussion. 

Paul


> On 13 Jan 2016, at 19:52, Costin Manolache <costin@gmail.com> wrote:
> 
> Direct connection would be faster and have fewer restrictions ( payload size, etc ), but would
> cost - both server resources, and load on the NATs ( some cheap NATs don't have lots of memory ).
> 
> Using the webpush connection: it helps keep it alive and reduces the competition for NAT entries. 
> The main cost for push service provider is keeping the connections open and doing the
> connection management.
> 
> Costin
> 
>> On Wed, Jan 13, 2016 at 4:05 AM, Paul Banks <banks@banksco.de> wrote:
>> Nice thanks!
>> 
>> > On 13 Jan 2016, at 10:15, Martin Thomson <martin.thomson@gmail.com> wrote:
>> >
>> > Paul, just for you: https://github.com/w3c/push-api/issues/179
>> >
>> >> On 13 January 2016 at 19:17, Paul Banks <banks@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.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
>> >>>>
>