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

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 <bbangert@mozilla.com> wrote:
> 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 <elioda@microsoft.com> wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ietf.org/mailman/listinfo/webpush
>>
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>