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

[Costin Manolache <[e-mail]>]

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]>
wrote:

> On Fri, 2016-06-10 at 07:33 +1000, Martin Thomson wrote:
> > On 10 June 2016 at 05:01, Kit Cambridge <[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 vs. 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é
>