On 20 October 2014 03:18, Shijun Sun <shij...@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.
