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

Re: Push API draft uploaded

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Tue, 05 Jun 2012 16:00:54 +0200
Message-ID: <4FCE1116.4090203@lamouri.fr>
To: public-webapps@w3.org
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 notifications,
> 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 of
> 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 have
> 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 user?
> An example of background work following a remote server event would be the
> 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 background
> 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 to
> 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.


Received on Tuesday, 5 June 2012 14:01:50 UTC

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