Re: Push API draft uploaded

On 5/30/12 11:14 AM, "Mounir Lamouri" <mounir@lamouri.fr> wrote:

>>> * I guess the idea of |onmessage| is that the PushService instance will
>>> get an event when the backend will push a notification to the webapp.
>>> However, I wonder how you do handle the situation when the application
>>> is actually not being ran. Or should we wait for it to be launched?
>>> Anyhow, coupling the URL request and the event handling at the same
>>> place seems weird.
>>>
>>> <bryan> Not at all. This is the way that EventSource works for example
>>>(the message handler is overtly associated with the request to a
>>>specific service URL). I'm not sure what you mean by "when the
>>>application is actually not being ran"... if you mean "when the app is
>>>not running", the answer is yes, the app should be started and the
>>>event then delivered to it.
>> 
>> Running a webapp/website then sending an event to it seems a rather hard
>> task. This is actually what motivated the "System Message Handler" API.
>> 
>> <bryan> I'm not sure how it's hard; the Webapp just arranges for Push
>>message delivery when it is invoked, and events are delivered to the
>>object that represents the service arrangement (whether connection-based
>>or connectionless or whatever). I may be missing your counterpoint.
>
>I wasn't clear I think. If you start an application because of a
>particular event, the application has no way to know it has been started
>because of the event until the event is actually sent. But the event
>will be sent at a point during load (or after) and in the meantime, the
>application might show a UI as if it was simply started by the user. So
>you might have a weird UI flickering where something will be shown and
>very quickly will be changed to something else because of the push
>notification coming.

Agreed with Mounir here. While passing an event to a running app makes
sense (and already exists in the form of EventSource) it really doesn't
for apps which are not running. Passing the event data as query params
seems more suitable in that case.

>>> * If we want want a |wakeup| attribute, this might need to live in the
>>> manifest as Jose suggested. In general, I wonder if that should be
>>> something the UA requests. I would understand why the UA would ignore
>>> |wakeup = true| but I wouldn't understand why it should always follows
>>> the passed value.
>>>
>>> <bryan> The wakeup feature might be turned on by the app through an
>>>interface with the user, and used sometimes and others not per the
>>>needs of the app and preferences of the user (app managed). If it's in
>>>the manifest, it's fixed. I don't believe the UA should ignore the
>>>requirements of the app, when the user has given their permission for
>>>its operation as needed (both by browsing/installing the app, and
>>>overtly by approving Push service use).
>> 
>> I'm not sure I understand how the user would give its permission here.
>> 
>> <bryan> By navigating to the Webapp (implicitly, in the case that the
>>Webapp had previously been permitted access to Push services by the
>>user), and by accepting the UA's prompt as to whether this app should be
>>allowed to receive Push messages the first time the user navigates to it
>>(explicitly).
>
>So the user doesn't really give its permission to the app to wakeup the
>device but to the app to be able to receive push notifications. Then,
>the app is the only one deciding if it will wakeup the device or not.
>I'm not a big fan of that approach but I don't really have a better idea
>for the moment.

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. :-/

Thanks,

--tobie

Received on Thursday, 31 May 2012 13:29:27 UTC