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

From: Elio Damaggio <[email-masked]>
Date: Fri, 30 Oct 2015 20:32:26 +0000

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

---

From: Benjamin Bangert <[email-masked]>
Date: Fri, 30 Oct 2015 15:16:16 -0700

I implemented this feature in our system and decided that I'd 404 the
request. The app-server will have to re-send it as a new request, but the
logic involved in making a new message (where it's found that we can't
update it) was complex enough that it was cheaper to push the retry to the
app-server.

Your second point still exists. If a client has pulled the message, but not
deleted it when the app-server sends an update then there's two possible
behaviors:
1) The new message the app-server sent in just got deleted
2) The delete is ignored because its not the same message anymore

In our case we choose option #2, the delete is ignored. We also don't plan
on generating a receipt for the failed delete, and when the updated message
is delivered, then the delete for it will work and the receipt will be sent.

I implemented this by tracking an additional internal message-id that is
replaced everytime the message is updated, this prevents a client from
deleting a message it got if it was just updated by the app-server.

The side-effect of all this, is that a client will process multiple
messages and send only the last receipt. I don't think that's too horrible
because its an edge-case, it seems unlikely that it'll be common for an
app-server to send in an update at just the right time for this.

The logical slot is the unique message ID URL, which seemed adequate.

Cheers,
Ben

On Fri, Oct 30, 2015 at 1:32 PM, Elio Damaggio <[email-masked]> wrote:

> 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
> ).
>
>
>
> 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.
>
> 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
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 31 Oct 2015 14:45:48 +0900

There is an alternative, which is to have the collapse be a POST to a
push message URL.  If the message is present, the contents are
updated, if the message was acknowledged, then a new message is
created.  Would that work?

The only real downside to this is that it isn't idempotent.

On 31 October 2015 at 07:16, Benjamin Bangert <[email-masked]> wrote:
> The side-effect of all this, is that a client will process multiple messages
> and send only the last receipt. I don't think that's too horrible because
> its an edge-case, it seems unlikely that it'll be common for an app-server
> to send in an update at just the right time for this.
>
>> 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).
>>
>>
>>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 31 Oct 2015 14:46:22 +0900

Oh, and it means that the recipient won't receive the collapse key.
Though we could add something for that too.