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

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

On 31 October 2015 at 14:45, Martin Thomson <martin.thomson@gmail.com> wrote:
> 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
>>