Responses to Push API Feedback from TAG

>From https://github.com/w3ctag/spec-reviews/blob/c218958ce2c9b655282bd1ebdbe93e8902b423e1/2013/08/Push%20API.md

API Field of Application

ISSUE: Concepts unclear

The Push API spec introduces a number of new concepts. In our view following terms and ideas should be explicitly defined in the document:

    push service
    invoking a non-active webapp
    pushRegistrationId as a form of user identification

These concepts raise a lot of questions which should be clarified. For example:

    why is push service needed?
    [bryan] The importance of Push services and in general server-initiated content delivery / notifications is indicated by the role of these in the market today, and the omission of them in the web is a significant gap in "closing the gap with native". Many use cases can be described in the spec, but due to the obvious value of this method we did not feel that was necessary. You can see the history of use case discussions in the process of adding this API to the Webapps charter: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html

    How should app server deal with push server knowing nothing except endpoint URL?
    [bryan] The question is unclear. The Push Server knows both the endpoint URL (pushEndpoint) and registration ID (pushRegistrationId). The combination of these two enables the Push Server to uniquely target the application on the device.

    What information is passing through push service and how is user-agent authenticated?
    [bryan] The current spec version includes only a notification that "something" is available at the App Server, but does not include delivery of any app-specific content. Thus all data transfered between the Push Server and User Agent is specific to the Push system in use, and not described here.

    how are registrations preserved between sessions and different webapp instances?
    [bryan] Registrations are unique to each webapp instance. The User Agent is responsible for persistent storage of the registration info - we do not specify how.

    What is webapp in a sense of this spec?
    [bryan] A webapp is a web-based application activated from an origin via a URL. The same as in all other cases. Once the webapp is activated, and a DOM structure created, the webapp is a unique object running under the User Agent.

    Do all same-origin webpages share the registrations?
    [bryan] No. They can however arrange a single shared worker that handles their common Push service.

    how should user-agent invoke an inactive webapp?
    [bryan] That is an implementation decision. The webapp is responsible for assigning a notification handler, the User Agent for everything else.

    How to invoke a webapp requested using POST (or PUT, or DELETE) method?
    [bryan] Invocation of the webapp is not related to the HTTP method that was used to originally activate the webapp.

    How to invoke a webapp that is using History API to manipulate page URLs?
    [bryan] The webapp is a unique object running under the User Agent and the use of the history API does not affect Push registrations, unless the history traversal resets/changes the DOM.

ISSUE: "Express permission" needs clarification

It is also unclear what "User agents must not provide Push API access to webapps without the express permission of the user" means.  Either "express permission" definition should be clarified or "MUST NOT" statement should be excluded.
[bryan] This is the way we have expressed user-authorized intent in DAP, to describe *that* (not *how*) User Agents without "prearranged trust relationships" for a webapp must engage the user in authorizing access to an API that is potentially security/privacy-sensitive.

ISSUE: NoModificationAllowedError needs clarification

Specification doesn't define when this error may occur and why webapp might be disallowed to unregister.
[bryan] The spec says "Check that the pushRegistrationId attribute relates to an active push registration of the requesting webapp or alternatively that the requesting webapp has permission to deactivate such push registration.
If none of them is fulfilled..." the error is thrown.

API Objects' Responsibilities

ISSUE: Access granting and push registering functionality stick together

PushManager.register provides two heterogeneous functions:

    asking use permission,
    registering push notifications.

This mixing leads to odd user agent behavior, i.e. push service failure forces webapp to ask permission again.

Suggestion: split the functionality and provide separate methods to ask user permission (check if permission has already being granted) and to register push notifications. Provide different sets of errors for those purposes.

[bryan] OK, to be considered.

API Objects' Interfaces

ISSUE: Indistinguishable registrations

PushManager provides mechanisms to register more than one push notifications request. It seems like useful functionality when webapp has different message streams or message sources. But neither user nor webapp cannot tell which registration belongs to which message stream. So user will be just confused if application would ask his permission to show push notifications several times in a row, and webapp would have to invent some mechanism to share "registrationId <-> message stream" relation between sessions and app instances.
[bryan] Webapps do know which registration belongs to them, via the PushRegistration interface. Webapps with multiple instances can use a shared worker if they are concerned about too much permission-asking.

Suggestion: allow webapp to provide (a) an alias for each registration, (b) some information for user regarding each registration.
[bryan] The suggestion is unclear given the response above.

ISSUE: Bad names

PushManager is limited to dealing with registrations. Suggestion: PushRegistrationManager.

navigator.push as an object of PushManager type seems misleading per se and is inconsistent with Array.prototype.push method. Suggestion: navigator.pushRegistrationManager.
[bryan] OK, to be considered.

PushManager.registrations method seems inconsistent. Suggestion: PushManager.getRegistrations.
[bryan] OK, to be considered.

AbortError is raised when user doesn't grant permissions, not when registration is aborted. Suggestion: PermissionDeniedError.
[bryan] OK, to be considered.

PushRegisterMessage name is confusing as it really occurs when push service failed, not when new registration granted. Suggestion: PushServiceFailure.
[bryan] OK, to be considered.

>From https://github.com/w3ctag/spec-reviews/blob/master/2013/08/Push_API_initial_comments.md

Dear Editors & Authors,

The TAG has been looking to do review of the Push API draft but, having reviewed the current spec, feel that there are issues with the draft that probably need discussion before we're able to proceed in providing detailed technical feedback.

A few examples.

First, while the introduction of the draft outlines a few underlying technologies that might generate push messages, it's not clear that there's a strong method for binding documents/URL space to these message types in any meaningful way. The API leaves the entire concept of routing of messages as an exercise for developers to navigate. We'd like to understand why the API was developed this way.

[bryan] The notion of "binding documents/URL space to messages" needs to be explained a bit further so I can understand the question, unless this answer indicates I already do. Push messages are not inherently "bound" to URL space as are conventional documents retrieved via HTTP, as there is as yet no globally supported standard for the "northbound" Push Server API which apps use to initiate Push requests. However it is defined in RESTful Push APIs on the network side (e.g. OMA's PushREST and earlier RPC-style Push Access Protocol specifications) that Push transactions are associated with resources (URI-based) that are created in the act of an app server initiating a Push request. Proprietary Push systems (Google, Apple, Blackberry, etc) may use other binding concepts, and one of the longer-term goals for Push services is to address a harmonized Push Server API, application Push service lifecycle, and perhaps a harmonized set of over-the-air/wire protocols for Push Server to Push Client (platform/OS or user agent, whichever is the first message receiver endpoint in the user device).
Next, the idea of a message queue is useful, but the choice to use hasPendingMessages() and setMessageHandler() instead of the well-worn DOM event model or the message APIs that exist in the platform (Message Ports / postMessage/onmessage) is, at best, head-scratching. We'd like to understand the thinking behind it.

[eduardo] Current draft is based on the concept of System Messages to wake up a non-running web app. System Messages were introduced in SysApps' 'Runtime and Security Model for Web Applications' spec [1] , which was abandoned some time ago in favor of  the 'Application Lifecycle' spec [2] , which does not define the System Messages. We need to define a mechanism to wake up non-running web apps. Jonas Sicking indicates Service Workers [3] could be used for that.
[1] http://www.w3.org/2012/sysapps/runtime/
[2] http://www.w3.org/2012/sysapps/app-lifecycle/
[3] https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md

As a final example, it's unclear from the code examples how web apps are meant to be invoked (or if they are at all) when push messages are delivered to users. If the system provides UI for interacting with the message, how does it relate to the web app? And if the system doesn't create a mapping between the two at registration time, does that mean that messages are only ever delivered to apps when users open them? Doesn't that make web apps permanently second-class? We'd like to understand the thinking there.

[bryan] That aspect is left out of scope, as current platforms do provide means for Push messages to be routed to the appropriate app or user agent, and in the browser case the user agent is the one responsible to delivering it to the app. The association of a particular message with an app or as part of a sequence of messages in a Push service session, is a discrete Push system design issue and related OTA/wire protocol concern at this point. We are enabling diverse underlying protocols and platform binding choices in the meantime, and may consider specifications for those in the future as needed. As mentioned, it is expected that the "system" (meaning the combination of user device and Push service) does create an app-specific binding, but we leave those details to implementations for now. Messages can be delivered to apps at any time, even if the app is not running (it can be invoked by the incoming message), but it will be up to the specific platforms to support or not such features, though for consistent developer experience it should be encouraged to support all of: delivery to app when in the foreground, background, or not running in an active web runtime window. We definitely want web apps to be first citizens, and that's one of the key reasons for promoting this spec.
We're optimistic that this is going to be an incredibly helpful API for apps and users and want to do what we can to help improve it. Thanks for your time and consideration.

Regards,

The TAG

Thanks,
Bryan Sullivan