Re: Push API and Service Workers

On 20 October 2014 03:18, Shijun Sun <shijuns@microsoft.com> wrote:

> What I'd like to get across is when the "push client" can handle generic
> actions already, such as posting a toast notifications, waking up the
> browser (or a subset of it) and let service workers to display each
> notification might not be the best practice from performance perspective,
>

Things I guess you'd do as a result of a push message:

* Update caches
* Show a notification
* Focus a tab & tell it to do something

Updating caches should be common, and it's something most native apps get
very wrong. Take Twitter for example, I can tap a notification that shows a
partial tweet, but I have poor/no connectivity so the full tweet doesn't
load. The notification is now gone, so I'm left with less information than
I had before I tapped the notification. Twitter should download and cache
the full tweet before showing the notification.

On top of that, there are conditions that could mean I don't want to show a
notification, or hide an existing one:

* User already has relevant content focused & visible
* User reads the content elsewhere (a push message would trigger the hiding
of the current notification)

Also, if the user dismisses the notification, I may wish to send that info
back to the server, and push a message that hides the notification on other
devices. When you multiply that all together, we've got a large API, and
we've probably done the appcache thing and forgotten about particular
use-cases.

In terms of RTC, let's imagine we receive a "Jeff's calling" push message.
At this point I'd want to:

* If there isn't a tab open to the calling app, open one
* Else use the existing one
* Focus it (forcing it over any lock screen - we don't have a way to do
this yet)
* postMessage the page telling it who's calling
* If a call is already in progress, show a small overlay indicating the new
call, with handling options
* Else show a full screen "Jeff's calling" message with handling options,
play ringtone until handled

If the call is answered on a particular device, you'll want to push to
other devices to stop "ringing".

That's a rough design for what I think should happen, other people may have
better ideas. I don't think now's the time to give a particular design a
high-level API. I'd rather follow the extensible web model and expose the
primitives, then build higher level bits based on common patterns that are
observed.