RE: Push API draft uploaded

Responses inline.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Tobie Langel [mailto:tobie@fb.com] 
Sent: Thursday, May 31, 2012 6:29 AM
To: public-webapps@w3.org
Subject: 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.

<bryan> If the event data can be passed through a fragment (e.g. there are no major limitations on that approach), and easily discovered/accessed by the app, then that would be a good approach. Can you provide an example of how that would work?

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

<bryan> Correct, the objective is application messaging, not user messaging. Like other aspects of the UX e.g. that supported by the Web since AJAX became popular, we don't think it's necessary or effective to require the user to be involved in all client-server interactions.

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)?

<bryan> Apps that can be automatically woken up would benefit from need enabling cooperative design that results in a good UX, e.g. the ability to be invoked and startup in the background, if there is another foreground app (whether in the Web runtime or a native app), and inform the user through whatever UI tools it has available (if needed - not all events need to result in a UI). Overall through if the user has chosen to allow an app to be invoked, and there is no system-level support for opening it up in the background etc, the user is probably aware of (can be informed of at least) that behavior and will come to expect it. This is similar to how users are familiar with phone apps taking the focus as needed. In the WebRTC use case this in fact the desired experience.

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?

<bryan> These are aspects that should be addressed in the spec (as I noted). I will add some placeholder sections which we can fill out and which may lead to normative requirements.

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.

<bryan> Whether the app should be woken up automatically, or the user given some kind of UI as information that a notification has been received, can be considered in the wakeup-registering interface, through which the user can expressly accept that the app can be woken up automatically. Apps will need varying ability to be woken up automatically; in the WebRTC use case it would be expected that the app may need to be woken up, since taking active steps to alert the user and setup the prerequisites to a peer connection (e.g. SDP) need to occur quickly, due to the expectation by the calling user that the called user will be informed and respond in some way quickly. There are clearly some use cases (mail may be one) for which Push message processing can wait until the user accesses a notification UI. But a variety of others (such as WebRTC) involving asynchronous notification of time-sensitive application data.

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?

<bryan> Perhaps, and your comments below are a good outline of how these two types of use cases can be addressed in the spec and help shape it. For my interests the primary use case types are that of a generic mechanism to send application data to apps, which can be bound to various delivery bearers. The invocation capability addresses one key app state: installed and registered with a Push service, but not running all the time, and addresses both the user and app notification purposes. The ability to be automatically invoked addresses time-sensitive app use cases.

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 Friday, 1 June 2012 17:35:03 UTC