Re: Push API and Service Workers

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