Intent to Implement: New Push API

Tyler Smith

unread,

Jul 21, 2014, 12:22:28 PM7/21/14

to dev-pl...@lists.mozilla.org

Summary: New Push API to replace the current specification for SimplePush.
Purposes include
1) Switching to Promise, which was sorely needed.
2) Establishing that the data field of messages is required.
3) Establishing that all background communication happens over HTTPS
4) Agreeing that the DOM API should not have to care what Push backend the
device is using
5) Playing nicer with the interface exposure model (earlier we just
wouldn't show navigator.push to apps without permission)
6) Supporting a feature set that at least one other implementer has agreed
upon, rather than what we just cooked up to support on fxos

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1038811

Link to Spec (informal disussion):
https://docs.google.com/document/d/1EeUDLsMLc1dtAk9uHVwnP1N8AFnH7vVVgec_h7BWlI4/edit?pli=1#

Distilled Spec:
Promise<PushRegistration> register() => registration, or promise rejected
if fails
Promise<boolean> unregister() => true if successful, else false
Promise<DOMString> hasPermission() => “need-ask”/”granted”/”denied” (never
fails)
Promise<boolean> isRegistered() => true, false, or promise rejected if
unknown

Platform Coverage: FXOS, Desktop FF, and Firefox Mobile

Preference: dom.push.enabled

We don't intend to break backwards compatibility with the old push system
in the immediate future. The navigator property for the new push API is
pushRegistrationManager, so the thinking right now is that for a few
releases the two will be offered side by side as completely distinct
services, but with the intent to remove the old push system at some point.

Martin Thomson

unread,

Jul 21, 2014, 1:46:46 PM7/21/14

to Tyler Smith, dev-pl...@lists.mozilla.org

The latest version of the API spec is here: https://w3c.github.io/push-api/index.html

That’s potentially in flux. What are your plans should something major change?

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Ehsan Akhgari

unread,

Jul 21, 2014, 2:00:13 PM7/21/14

to Tyler Smith, dev-pl...@lists.mozilla.org

On 2014-07-21, 12:22 PM, Tyler Smith wrote:
> Summary: New Push API to replace the current specification for SimplePush.
> Purposes include
> 1) Switching to Promise, which was sorely needed.
> 2) Establishing that the data field of messages is required.
> 3) Establishing that all background communication happens over HTTPS
> 4) Agreeing that the DOM API should not have to care what Push backend the
> device is using
> 5) Playing nicer with the interface exposure model (earlier we just
> wouldn't show navigator.push to apps without permission)

Can you please clarify what you mean here? How are you looking to
expose the new property?

Also, I'm not sure if you're just trying to implement this hidden behind
a preference or if you are thinking about shipping it by default.

> 6) Supporting a feature set that at least one other implementer has agreed
> upon, rather than what we just cooked up to support on fxos

I assume that is Blink? (That's great news BTW!)

> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1038811
>
> Link to Spec (informal disussion):
> https://docs.google.com/document/d/1EeUDLsMLc1dtAk9uHVwnP1N8AFnH7vVVgec_h7BWlI4/edit?pli=1#
>
> Distilled Spec:
> Promise<PushRegistration> register() => registration, or promise rejected
> if fails
> Promise<boolean> unregister() => true if successful, else false
> Promise<DOMString> hasPermission() => “need-ask”/”granted”/”denied” (never
> fails)
> Promise<boolean> isRegistered() => true, false, or promise rejected if
> unknown
>
> Platform Coverage: FXOS, Desktop FF, and Firefox Mobile
>
> Preference: dom.push.enabled
>
> We don't intend to break backwards compatibility with the old push system
> in the immediate future. The navigator property for the new push API is
> pushRegistrationManager, so the thinking right now is that for a few
> releases the two will be offered side by side as completely distinct
> services, but with the intent to remove the old push system at some point.

Hmm, the spec here <https://w3c.github.io/push-api/index.html> talks
about navigator.push. Is that something that is going to change in the
spec?

Cheers,
Ehsan

nmar...@mozilla.com

unread,

Jul 21, 2014, 4:25:24 PM7/21/14

to

On Monday, July 21, 2014 11:00:13 AM UTC-7, Ehsan Akhgari wrote:
> On 2014-07-21, 12:22 PM, Tyler Smith wrote:
>
> > Summary: New Push API to replace the current specification for SimplePush.
>
> > Purposes include
>
> > 1) Switching to Promise, which was sorely needed.
>
> > 2) Establishing that the data field of messages is required.
>
> > 3) Establishing that all background communication happens over HTTPS
>
> > 4) Agreeing that the DOM API should not have to care what Push backend the
>
> > device is using
>
> > 5) Playing nicer with the interface exposure model (earlier we just
>
> > wouldn't show navigator.push to apps without permission)
>
>
>
> Can you please clarify what you mean here? How are you looking to
>
> expose the new property?

Ah, this is my fault in explaining things a bit wrong to Tyler. It'll be exposed the way we expose all the other APIs, nothing special. It will be hidden behind dom.push.enabled, although I'd like it to be enabled by default on non Release builds. The new spec is exposed as navigator.pushRegistrationManager so it does not conflict with navigator.push.

>
> Hmm, the spec here <https://w3c.github.io/push-api/index.html> talks
>
> about navigator.push. Is that something that is going to change in the
>
> spec?

Sadly the spec hasn't been updated in several months. Eduardo, one of the editor's intends to get on it in August after he is back from vacation.

Nikhil

Ehsan Akhgari

unread,

Jul 21, 2014, 5:01:27 PM7/21/14

to nmar...@mozilla.com, dev-pl...@lists.mozilla.org

On 2014-07-21, 4:25 PM, nmar...@mozilla.com wrote:
> On Monday, July 21, 2014 11:00:13 AM UTC-7, Ehsan Akhgari wrote:
>> On 2014-07-21, 12:22 PM, Tyler Smith wrote:
>>
>>> Summary: New Push API to replace the current specification for SimplePush.
>>
>>> Purposes include
>>
>>> 1) Switching to Promise, which was sorely needed.
>>
>>> 2) Establishing that the data field of messages is required.
>>
>>> 3) Establishing that all background communication happens over HTTPS
>>
>>> 4) Agreeing that the DOM API should not have to care what Push backend the
>>
>>> device is using
>>
>>> 5) Playing nicer with the interface exposure model (earlier we just
>>
>>> wouldn't show navigator.push to apps without permission)
>>
>>
>>
>> Can you please clarify what you mean here? How are you looking to
>>
>> expose the new property?
>
> Ah, this is my fault in explaining things a bit wrong to Tyler. It'll be exposed the way we expose all the other APIs, nothing special. It will be hidden behind dom.push.enabled, although I'd like it to be enabled by default on non Release builds. The new spec is exposed as navigator.pushRegistrationManager so it does not conflict with navigator.push.

That sounds good.

>> Hmm, the spec here <https://w3c.github.io/push-api/index.html> talks
>>
>> about navigator.push. Is that something that is going to change in the
>>
>> spec?
>
> Sadly the spec hasn't been updated in several months. Eduardo, one of the editor's intends to get on it in August after he is back from vacation.

Understood. No concerns form me there as long as we keep up with the
developments on the spec side as our implementation makes progress.

Cheers,
Ehsan

Jonas Sicking

unread,

Jul 24, 2014, 1:03:07 AM7/24/14

to Tyler Smith, dev-platform

There were discussionsa about moving the API from navigator.push to
serviceWorkerRegiatration.push. This would make a lot of sense to me given
that the registration is tied to a service worker rather than a page.

Is this what you are planning to implement? It would be good to avoid
shipping more than two versions of the API in release builds.

/ Jonas

On Jul 21, 2014 9:23 AM, "Tyler Smith" <tyls...@gmail.com> wrote:
>
> Summary: New Push API to replace the current specification for SimplePush.
> Purposes include
> 1) Switching to Promise, which was sorely needed.
> 2) Establishing that the data field of messages is required.
> 3) Establishing that all background communication happens over HTTPS
> 4) Agreeing that the DOM API should not have to care what Push backend the
> device is using
> 5) Playing nicer with the interface exposure model (earlier we just
> wouldn't show navigator.push to apps without permission)

> 6) Supporting a feature set that at least one other implementer has agreed
> upon, rather than what we just cooked up to support on fxos
>

> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1038811
>
> Link to Spec (informal disussion):
>
https://docs.google.com/document/d/1EeUDLsMLc1dtAk9uHVwnP1N8AFnH7vVVgec_h7BWlI4/edit?pli=1#
>
> Distilled Spec:
> Promise<PushRegistration> register() => registration, or promise rejected
> if fails
> Promise<boolean> unregister() => true if successful, else false
> Promise<DOMString> hasPermission() => "need-ask"/"granted"/"denied" (never
> fails)
> Promise<boolean> isRegistered() => true, false, or promise rejected if
> unknown
>
> Platform Coverage: FXOS, Desktop FF, and Firefox Mobile
>
> Preference: dom.push.enabled
>
> We don't intend to break backwards compatibility with the old push system
> in the immediate future. The navigator property for the new push API is
> pushRegistrationManager, so the thinking right now is that for a few
> releases the two will be offered side by side as completely distinct
> services, but with the intent to remove the old push system at some point.