- From: Erik Corry <erikcorry@google.com>
- Date: Tue, 21 Oct 2014 15:25:56 +0100
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: Shijun Sun <shijuns@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, Domenic Denicola <domenic@domenicdenicola.com>, public-webapps <public-webapps@w3.org>
Some drive-by observations: * Push needs SW because you want to be able to run code when a push message arrives, but you don't want to do that in the whole browser, which is too heavy. * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things to a local database, but does not cache/intercept a web page. * This ties into the discussion of whether it should be possible to register a SW without giving it a network-intercept namespace On Mon, Oct 20, 2014 at 5:42 PM, Jake Archibald <jaffathecake@gmail.com> wrote: > 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. -- Erik Corry Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
Received on Thursday, 23 October 2014 20:50:04 UTC