Re: Push API draft uploaded

On 06/05/2012 09:27 PM, Tobie Langel wrote:
> 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.

Would the CPU waste be significant enough? Doesn't seem that this would
eat that much CPU time relatively to what is required for the entire
process (from push coming to the device trough the network to the
notification being shown to 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.

The main issue I would see with that is that some applications might use
query params already and we can't really put any data we want in query
params.

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

Sure.

--
Mounir

Received on Tuesday, 5 June 2012 21:35:46 UTC