Re: [w3c/push-api] Add Declarative Web Push (PR #385)

@beverloo commented on this pull request.



> +          }
+        </pre>
+        <section>
+          <h3>
+            Members
+          </h3>
+          <p>
+            A [=declarative push message=] has the following members:
+          </p>
+          <dl>
+            <dt>
+              <code>web_push</code> (required)
+            </dt>
+            <dd>
+              <p>
+                An integer that must be 9001. Used to disambiguate a [=declarative push message=]

As much as I appreciate 9001, we should also consider 8030? (Referring to the Web Push RFC.)  Or some number that reflects the collective number of grey hairs we have over this stuff, which is definitely over 9000 😄 

> +          </h3>
+          <p>
+            A [=declarative push message=] has the following members:
+          </p>
+          <dl>
+            <dt>
+              <code>web_push</code> (required)
+            </dt>
+            <dd>
+              <p>
+                An integer that must be 9001. Used to disambiguate a [=declarative push message=]
+                from other JSON documents.
+              </p>
+            </dd>
+            <dt>
+              <code>notification</code> (required)

Is there any way in which this can simply match [`NotificationOptions`](https://notifications.spec.whatwg.org/#dictdef-notificationoptions) with a required title and URL? I guess this being JSON makes that difficult? Both the partial selection of available options and the duplication this introduces makes it fragile and more difficult to reason about.

> +                    Any JSON value.
+                  </p>
+                </dd>
+                <dt>
+                  <code>mutable</code>
+                </dt>
+                <dd>
+                  <p>
+                    A boolean. When true causes a <code>pushnotification</code> to be dispatched to
+                    a service worker (if any).
+                  </p>
+                </dd>
+              </dl>
+            </dd>
+            <dt>
+              <code>app_badge</code>

There really are three features being added here:
1. Declarative push notifications (w/ the Web Notification API),
2. Declarative push notifications that also fire a JavaScript event,
3. Declarative app badge updating (w/ the Badging API).

I think it'd be helpful to think about them separately. Intuitively I'm in favour of (1) and (3), however I have some concerns about (2).

A large part of our interest in declarative notifications comes from device resource usage improvements that it enables in Web Push message delivery, and from time-to-feedback improvements when users activate a Web Notification.

If the design were to stick to features (1) and (3), it would remove the need to launch a renderer process in Chrome entirely, which brings major savings (& with enough time and determination we could even trim much of our browser process). The `mutable` property would remove that optimisation, and based on our experience I expect it to be adopted for purposes of (at least) sending analytics pings back to the server. There may be other ways to solve for that use case too.

@beidson describes this as:
> We also propose a more flexible event handling model that developers can opt into to transform a push notification. This new model still depends on Service Workers, but provides the privacy-preserving guarantee that there is always a fallback notification to be shown, so pushes cannot trigger silent background runtime.

Existing implementations already solve for this: Chrome shows a default notification on behalf of the website, and IIRC Firefox and Edge penalize and eventually remove the underlying push subscription. I don't understand what benefit this brings over existing functionality.

I propose scoping out this concept from the proposal as it'll need more discussion.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/pull/385#pullrequestreview-2284136922
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/push-api/pull/385/review/2284136922@github.com>