Re: Web Push API intended scope

[Ben Last]

On 12 January 2016 at 20:38, Martin Thomson 
wrote:

> The Push API is intended for infrequent messages


I don't recall this being stated as a design goal or implicit requirement,
though I may have missed it. What counts as *infrequent* in this context?

Regards
Ben

Re: Web Push API intended scope

[Martin Thomson]

On 16 January 2016 at 08:06, Ben Last  wrote:
> I don't recall this being stated as a design goal or implicit requirement,
> though I may have missed it. What counts as infrequent in this context?

Maybe it wasn't express, but implied.

There are a few simple drivers for this:

1. Push messaging is intermediated and relatively slow and expensive;
direct communication is always cheaper and faster
2. ...but only when you already have a connection; maintaining a long
term connection from multiple clients is very expensive.

Therefore, push is best used when you don't have a direct
communication channel open to your site.  Use direct connections when
available, but let them close and use push when you aren't actively
using them.

Re: Web Push API intended scope

[Paul Banks]

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

Re: Web Push API intended scope

[Martin Thomson]

Paul, just for you: https://github.com/w3c/push-api/issues/179

On 13 January 2016 at 19:17, Paul Banks  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  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  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
>>>

Re: Web Push API intended scope

[Paul Banks]

Nice thanks!

> On 13 Jan 2016, at 10:15, Martin Thomson  wrote:
> 
> Paul, just for you: https://github.com/w3c/push-api/issues/179
> 
>> On 13 January 2016 at 19:17, Paul Banks  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  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  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
 

Re: Web Push API intended scope

[Paul Banks]

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  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  wrote:
>> Nice thanks!
>> 
>> > On 13 Jan 2016, at 10:15, Martin Thomson  wrote:
>> >
>> > Paul, just for you: https://github.com/w3c/push-api/issues/179
>> >
>> >> On 13 January 2016 at 19:17, Paul Banks  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  
>> >>> 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  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 
>>  

Re: Web Push API intended scope

[Martin Thomson]

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