- From: Kagami Sascha Rosylight <notifications@github.com>
- Date: Fri, 31 Jan 2025 07:39:34 -0800
- To: w3c/push-api <push-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/push-api/pull/385/review/2587101385@github.com>
@saschanaz commented on this pull request. > + </p> + </li> + <li> + <p> + Let |fallbackTimestamp| be [=current coarsened wall time=]. + </p> + </li> + <li> + <p> + Let |declarativeResult| be the result of running the [=/declarative push message + parser=] given |bytes|, |origin|, |baseURL|, and |fallbackTimestamp|. + </p> + </li> + <li> + <p> + If |declarativeResult| is not failure: It's sorta surprising that this implicitly parses all push payloads as declarative push and then falls back, I wonder an explicit option on subscription would make more sense. > + </dt> + <dd> + <p> + A boolean. + </p> + </dd> + <dt> + <code>silent</code> + </dt> + <dd> + <p> + A boolean. + </p> + </dd> + <dt> + <code>require_interaction</code> (If the casing was same the parsing step could just say "parse it as NotificationOptions" after extracting `title` first. And then updating notification options wouldn't require updating both specs.) -- Reply to this email directly or view it on GitHub: https://github.com/w3c/push-api/pull/385#pullrequestreview-2587101385 You are receiving this because you are subscribed to this thread. Message ID: <w3c/push-api/pull/385/review/2587101385@github.com>
Received on Friday, 31 January 2025 15:39:38 UTC