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

[RUELLAN Herve <[e-mail]>]

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é