Re: Push API draft uploaded

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
>>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/a3
>c6e4c31d04b663/

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
user.

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?

--tobie

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