Re: [Webpush] Message update PR

- +1 in general

- Doubts about the name "Topic" - many pubsub users will be confused, it is
not really a topic,
just a key

-  We may relax the '4 collapse keys' limit for GCM, shouldn't be a problem
for webpush.

Can we change a bit the wording to allow some optimizations we do: a
message with topic (collapse
key) may be optimized for 'sync usage' - i.e. even if the device is online,
if push service detects
frequent messages in a topic (for example user receives lots of email) it
may delay and collapse
messages. I.e. not only " If the user agent is offline".

Also I would prefer (for implementation purpose) a simpler ID syntax
instead of quoted string.
It's going to be a database key, short an unambiguous seems better. URI
path component would
be nice.

Finally, a more generic approach would be to allow the sender to specify a
MessageID - than
multiple messages with the same ID could override each other ( identical
with topic ), but the main
benefit is that senders will avoid a lookup and mapping push-service IDs to
their internal IDs in
acks. Push service can internally combine the subscription ID with the
sender-provided message ID.

Costin

On Sat, Jan 9, 2016 at 1:10 AM, Brian Raymor <Brian.Raymor@microsoft.com>
wrote:

> Is there any further feedback for Martin's pull request below?
>
> Thanks,
> ...Brian
>
> -----Original Message-----
> From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin
> Thomson
> Sent: Thursday, November 12, 2015 1:00 PM
> To: webpush@ietf.org
> Subject: [Webpush] Message update PR
>
> https://github.com/webpush-wg/webpush-protocol/pull/62
>
> The above pull request and commit is the substance of what we
> discussed in Yokohama regarding push message updates.  This proposes a
> new header field, Topic, which can be added to a push message.
>
> This doesn't really replace messages in the same way that the last one
> does.  Instead, it causes the old message to be acknowledged/deleted
> at the same time that the new message is created.  This avoids all the
> nasty race conditions we discussed at the meeting.  If the old message
> is being delivered, then this causes it to be acknowledged early;
> since acknowledgment is idempotent, there are no race conditions.
>
> --Martin
>
> _______________________________________________
> 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
>