Re: [Webpush] Non-blocking comments on -05

[Brian Raymor <[e-mail]>]

My opinion is that we do not need to block on potential/experimental (“might include”) use cases.

If there are no strong objections and/or further edits for Herve, I’ll merge/edit this PR later today.


From: Costin Manolache [mailto:[e-mail]]
Sent: Friday, June 10, 2016 10:18 AM
To: RUELLAN Herve <[e-mail]>fr>; [e-mail]
Cc: Brian Raymor <[e-mail]>om>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Webpush] Non-blocking comments on -05

Most use cases mentioned - with the exception of 'moving subscription' - can be implemented
efficiently by storing the messages keyed by some 'primary' ID. For large numbers, it
is desirable to optimize the number of DB queries done at connect - i.e. do a single read that
hits a single shard.  Most of the time the read will return empty, but the locality of the
messages for a single device is pretty important.

Moving subscriptions pretty much requires a different design - and I don't have any experience
with how it can scale.

Costin



On Fri, Jun 10, 2016 at 3:17 AM RUELLAN Herve <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, 2016-06-10 at 07:33 +1000, Martin Thomson wrote:
> On 10 June 2016 at 05:01, Kit Cambridge <[e-mail]<mailto:[e-mail]>> wrote:
> > Does moving a subscription set mean another UA would be able to receive messages sent to subscriptions in that set? (That is, without requiring the old UA to drop all its subscriptions and the new UA to reregister).
>
> I think that you have it. If you have 2 subscriptions that are in the
> same set, they have to be monitored together.  If they are in separate
> sets, then they can be monitored separately.  The separation enables
> intermediation.
>
> I don't think that this is a use case that is particularly important
> for the web case; I confess that it isn't that interesting to me.
> However, I think that it is an entirely valid use case, and it costs
> little.  It does however enable things on the web side that *are* very
> interesting to me.
>
> Say you have a UA that wants to go into a deep sleep to save power.
> In that mode, it still wants to receive push messages from several
> high priority sites.  But it doesn't want to get the deal-of-the-day
> and all that junk from other sites.
>
> Now, the UA knows that the push service is unable to discriminate
> between important and unimportant properly and it doesn't want to risk
> getting things like text message notifications from unimportant sites.
> Even if these are normally sent with moderately high urgency,
> legitimately.
>
> If it can split the important sites and the unimportant sites into two
> subscription sets, then it can monitor the important sites only.
> That's not possible if you don't allow the UA to control which
> subscriptions get grouped together.
>
> If you want a concrete example, think pagerduty.com<http://pagerduty.com> vs. skype.com<http://skype.com>.  A
> call might be entirely undesirable at 3am, but if a production site is
> on fire, it's wake up time.

As there seems to be several use cases here (your use case for the web,
Costin's multi-user case in android, and my UA proxying use case), I
think more of them could be listed in the spec.

How about:

Each subscription set can then be managed independently, which might
include monitoring only a set of very important subscriptions, handling
subscription for different users separately, or moving a subscription
set between user agents.


For moving subscription sets between UA, I agree that it's too early to
solve it in this Webpush draft. My concern here is to leave open the
possibility of building it in the future.

Hervé