W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Push API draft uploaded

From: Tobie Langel <tobie@fb.com>
Date: Tue, 5 Jun 2012 19:27:57 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <CBF3E5E0.85E2F%tobie@fb.com>
On 6/5/12 4:00 PM, "Mounir Lamouri" <mounir@lamouri.fr> wrote:

>On 05/31/2012 03:28 PM, Tobie Langel wrote:
>> I'm probably missing something here, but notifications don't seem to be
>> going through a system- / browser-wide notification panel from which the
>> user can decide whether or not to navigate to an application. In other
>> words, it looks like we're considering server --> app push
>> rather than server --> user push notifications.
>> If that's case, how are we planning to handle waking up application A
>> without disrupting the experience of the user currently busy using
>> application B in the foreground (thinking essentially of mobile here)?
>> Are we going to wake up application B but run it as a background app? If
>> so, where is that behavior defined? Is that akin to a WebWorker or more
>> a headless window? What's the life-cycle of such an app? Also, how can
>> this app alert the user that it has something new for him? Do we also
>> system level notifications in the work?
>> If a given notification's sole purpose is to advise the user of some
>> information he may or not want to act upon (e.g.: "you have new mail"),
>> what are the benefits of waking up the application (or even spawning a
>> worker) to do so? That seems like it would drain the battery of mobile
>> devices for little purpose.
>> Finally, aren't we conflating the notion of background work following a
>> remote server or system event with that of push notification to the
>> An example of background work following a remote server event would be
>> background update of daily news for a newspaper application. A remote
>> server would send an event to the system / browser which itself would
>> launch a WebWorker, that worker would perform the necessary io to upload
>> the fresh content and save it in a db.
>> An example of background work following a system event would be a
>> "location change" event spawning a background worker which itself either
>> stored the coordinates in a db or sent them to a remote server, e.g.
>>for a
>> cycling app tracking your rides.
>> Example of push notifications for the user are things like "You've got a
>> new message", "It's Emma's birthday today", etc. The user can decide to
>> act upon them (i.e. follow the provided link) or not, but until he does,
>> there's no reason to launch an app or even a worker.
>> Note that similar notifications would also need to be issued by
>> workers / windows. E.g. The worker spawned above to upload fresh content
>> for the newspaper app would be able to send a notification to the user
>> when it's done (e.g. "Today's news are  been downloaded.")
>> Sorry if the above feels a bit like a brain dump. I'm really struggling
>> understand the scope of this proposal. :-/
>Actually, our System Message API [1] seems to answer most of those
>questions: an application will be able to specify a worker or a page to
>use when handling a message so it will be able to just run stuff in the
>background and depending on what happened do something like show a
>notification (via Desktop Notifications) or update a DB, or whatever.

Thanks for the link!

While it's possible to display push notifications to the user via this
proposal (push notification spawns a worker which notifies the user via
Desktop Notification), on mobile it's probably a quantifiable waste of
battery life compared to push notifications that are directly aimed at the

For applications built in a more traditional way (with server side
rendering, etc.), it still feels like providing the data in query params
should be investigated before it's dismissed.

Overall, I feel like writing down use cases and requirements would be
something useful to do at this point. What do you think?

Received on Tuesday, 5 June 2012 19:30:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:40 UTC