Re: Push API draft uploaded

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