[Webpush] [Coalesce] Concern about PUT creating a new push message

[Elio Damaggio <[e-mail]>]

Hi,

Reviewing the current proposal for coalescing, I noticed this sentence.

+          However, a push service is encouraged
+          to treat an update for a removed push message as though the message
+          were still present and consequently send the push message to the user
+          agent.  Permitting an update avoids the additional request required to
+          retry and the associated delays.

In my opinion, if the desired behavior is to be able to "update or insert" in a logical "slot" (in the current proposal we are using the push message location), I would prefer to explicitly call it out as something akin to GCM "collapse-key" (https://developers.google.com/cloud-messaging/concept-options?hl=en#collapsible_and_non-collapsible_messages).

The collapse-key is more aligned on what we are planning to implement in Azure.

While I understand the cost of an additional concept, the current approach has two negative consequences:

1)      Application servers have to consider the optional behaviors on the send side.

a.      Note that on the client side (given the raciness of message collapsing), server support for collapsing has little impact on the design of the push handler.

2)      It makes acknowledgement harder to process, as now the same push can be acknowledged multiple times.

a.      This could be solved by returning a different push location in case the PUT results in an insert, but that complicates the concept of a push id, and makes the interface very un-RESTful (?), as we use a PUT on resource /a, to create a resource in /b.

Thoughts?

Elio