Re: [Webpush] Message update PR

[Costin Manolache <[e-mail]>]

On Mon, Jan 11, 2016 at 3:57 PM, Martin Thomson <[e-mail]>
wrote:

> On 12 January 2016 at 04:00, Costin Manolache <[e-mail]> wrote:
> > - +1 in general
> >
> > - Doubts about the name "Topic" - many pubsub users will be confused, it
> is
> > not really a topic,
> > just a key
>
> I'm happy to take suggestions on the name, it's just a name :)
>

'collapse_key' is what is used in GCM, I think having 'collapse' or
'override' or
'replace' or 'update' in the name would describe what happens.


>
> From my perspective however, the pubsub use fits almost perfectly with
> this use, so I think that the name is a bit of an advantage.
>

I don't think it fits so well.
If you publish 3 messages on a pubsub topic, you expect subscribers to get
3 messages,
not to have them all collapsed. And the topic is mapped to a list of
receivers, etc.

I know broadcast is not in scope for this release - but if/when we add it,
it will make things
more confusing with topic.


> > -  We may relax the '4 collapse keys' limit for GCM, shouldn't be a
> problem
> > for webpush.
>
> That would be awesome (I hear that collapse keys are very heavily used
> by some big sites, I wonder if you aren't already feeling the pressure
> there).
>

The intent of having just 4 keys was to encourage senders to use 'collapse'
just for sync,
and not attempt too much granularity. You tell the device to sync, with
some info (10 mails and 7 spams),
this gets updated while device is offline - and results in one sync that
fetches everything.

A single collapse key may have been better, to avoid confusion :-). At that
time it was not yet
clear how well things will work, and sync was the main use case. Most
senders with collapse
seem to be using a single key.



>
> > 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".
>
> That should always be possible.  If the text implies otherwise, then
> we should correct that.
>
> > 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.
>
> Would the base64(url) alphabet suit you well enough?  I didn't add
> that restriction.
>
> What about a length restriction?  I think that Ben and I discussed
> just rejecting push messages with ridiculously long topic names.
>
>
Agreed, base64(url) with a reasonable size is good.

A 64-bit long or UUID would be great too. AFAIK most collapse keys are 2..4
letters ( mail, cl,
all, sync ...)



> > 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.
>
> Maybe I'm not understanding you here, but isn't that exactly what this
> change does?
>

Not sure :-)

Current patch requires the messages to include the topic header, and it
still
generates 3 message IDs ( "creates a new push message resource")

Alternative would be to just allow updating the original resource, if it was
not sent.

BTW - there is one important change in the patch, allowing push senders to
DELETE
the resource. Allowing update would be consistent with that.


Costin