- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Tue, 05 Jun 2012 16:00:54 +0200
- 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. [1] https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3c6e4c31d04b663/ Cheers, -- Mounir
Received on Tuesday, 5 June 2012 14:01:50 UTC