[w3c/push-api] Allow Subscription via TOPIC headers (#189)

For those not on the IETF mailing lists, please see below.

In summary at least one of the message service providers (GCM) currently support Topic-Subscriber Mapping (broadcasting) and subscription-filtering based on topics. See: -

https://developers.google.com/cloud-messaging/topic-messaging#managing_topic_subscriptions_from_the_server 
and 
https://developers.google.com/instance-id/reference/server#create_a_relation_mapping_for_an_app_instance

What would be really helpful would be a mechanism for the WebPush client to subscribe to the TOPIC(s). See my /SEVERITY/REGION topic example on the weather web-app below.

Now I personally don't think it should go in the "options" of PushManager.subscribe(options) but let's not spend a year thinking about it?

Cheers Richard

>From IETF mailing lists: - 

Richard Maher <maherrj@googlemail.com>
11:20 AM (7 minutes ago)

to Benjamin, Kit, jr, webpush 
Here we go again :-(

> This mailing list is to discuss the IETF WebPush protocol

Yes, a living and evolving document. Let's not seek to censor the discussion or spit the dummy.

> while some
> push implementations have inspired additions, 
> they are separate from the spec that browsers 
> are working to implement.

An interesting opinion. IMHO, that demarcation is so narrow and restrictive that's it's no wonder that real world technology in the wild has rendered these standards redundant.

Once again, Web-Apps are deliberately being denied the life-giving functionality of native Apps by design.

Is this more about Mozilla's free messaging service not be resourced sufficiently in order to match GCM functionality?

I can see the Google involvement but I suggest we need more. AWS around?

> For WebPush, thats the primary intention.

Who voted for that??? 

Look FWIW I'll vote no to this standard as a moratorium on bureaucracy is required until the terms of reference has been revisited. Bit more RAD, Agile, Iterative, Buzz-word methodology needed here? Surely only those on the receiving end of Panama could vote for such a WebPush killer :-(

> What you're referring to has been proposed as
> the WebPush aggregation spec, which can be found here:
> https://github.com/martinthomson/webpush-aggregate

No it is not and please do not put words in my mouth. I want the broadcasting capability that GCM is offering today and I think I can already achieve it at the App server but the subscription mapping should to be done at the client. Just give us another PushManager,subscribe(option).

Cheers Richard



On Wed, Apr 6, 2016 at 10:54 AM, Benjamin Bangert <bbangert@mozilla.com> wrote:
On Tue, Apr 5, 2016 at 7:45 PM, Richard Maher <maherrj@googlemail.com> wrote:
> Hi Benjamin,
>
>> https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-6.4
>
> Now I'm completely lost and more than a tad disappointed.

This mailing list is to discuss the IETF WebPush protocol, while some
push implementations have inspired additions, they are separate from
the spec that browsers are working to implement.

>
>> That is documentation for Google Cloud Messaging,
>
> I know. I, perhaps wrongly, assumed the consumers of GCM (et al) would take
> full advantage of the infrastructure. "Collapsing" is a very useful
> optimization option but surely not the raison d'etre of topics?

For WebPush, thats the primary intention.


> I want to subscribe to /SEVERE/PERTH topics for push messages my weather
> app. The fact that old messages are collapsed is wonderful but if you're
> also going to bombard me with /MILD/TIMBUKTU messages (and so on) then I'm
> not too happy.
>
> I want to subscribe to the BHP stock ticker broadcasts and then maybe add
> FMG but I don't want the ASX 200.
>
> Have I really imagined that GCM cann do that?

GCM can, WebPush cannot. What you're referring to has been proposed as
the WebPush aggregation spec, which can be found here:
https://github.com/martinthomson/webpush-aggregate

Cheers,
Ben

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/189