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