Allow Subscription via TOPIC headers

[RichardMaher]

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

[beverloo]

As you can read in the abstract of the Push API, this API is being designed specifically for use with the Web Push Protocol, not to provide the union of features provided by the many push services out there.

This specification is designed for use with the web push protocol, which describes how an application server or user agent interacts with a push service.

Topics can be considered a version of aggregation, which is not in scope of the problems the working group is currently trying to solve, so I'm afraid this feature request is a WontFix from the Push API's point of view.

[martinthomson]

@beverloo is correct, but more to the point, this is a can't fix. Closing.

[RichardMaher]

I am at a complete loss to explain why someone would deliberately seek to ham-string the Web Push API and then go on to shoot itself in the foot after putting out enough sand-bags to ensure that it could never compete with native App API implementations :-(

As you can read in the abstract of the Push API, this API is being
designed specifically for use with the Web Push Protocol,

Did you miss this bit: -
[[[[[[
Alternative protocols could be used in place of this protocol, but this specification assumes the use of this protocol; alternative protocols are expected to provide compatible semantics.
]]]]]]

How the Application Server communicates with the push service is of little concern to you and thankfully outside your sphere of influence. When is comes to the UA it is the same feature-detection, degrade-gracefully, iterative and incremental development that we all know and love. If a particular UA does not support topic-based subscription then so be it. Nothing in that feature limitation mandates a lowest-common-denominator approach for the specification.

not to provide the union of features provided
by the many push services out there.

“Broadcasting” is an intrinsic and integral part of any Push Messaging architecture! Even if it’s not there in V1.0, surely the hooks should be left in place for future improvements? With the MBONE team looking to finally release something, the performance improvements could be amazing!

• BROADCASTING
• PRIORITY
• TTL
• COLLAPSE_KEY
• TOPIC Subscription

They are just some of the desirable features on the futures list. The beauty is that POC implementations are already out there; the work’s been done.

I'm afraid this feature request is a WontFix from the Push API's point of view.

Is there nobody here at Martintown Guyana willing to suggest we’re going the wrong way? Mozilla abandoned Simple Push and Microsoft is coming onboard with the Web Push API. Their users are getting Fed up with design 180s. Please make the design extensible!

Am I not asking for goodness?

“Thank-you for not discussing the outside world.”
– W3C and IETF mgmnt.

[RichardMaher]

@martinthomson can you please explain exactly why you consider this a "can't fix"?

[RichardMaher]

Great minds (not just Google): -

https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifications-to-millions-of-devices-with-windows-azure-notification-hubs/

Efficient tag-based multicast and pub/sub routing. Devices can specify one or more tags when registering with a Notification Hub. This indicates a user’s interest in notifications for a set of topics (favorite sport/teams, geo location, stock symbol, logical user ID, and so on). These tags don’t need to be pre-provisioned or disposed, and provide a very easy way for apps to send targeted notifications to millions of devices with a single API call, without you having to implement your own per-device notification routing infrastructure.

https://aws.amazon.com/sns/

Engage audiences directly or all-at-once
Use direct-addressing to send messages to individual devices or broadcast to multiple destinations at-once.

Who'd 've thunk it?

Those who can, do! Those that can't, teach! Those who couldn't find their arse in the dark with two hands and a torch, write standards!

[chaals]

Hi Richard,

I understand that you are feeling frustrated, but this group expects even annoyed participants to show a level of civility higher than your comments are reflecting.

[RichardMaher]

C'mon Chuck, surely most readers here agree that there is far more mirth and merriment in my posts than there is malice? Look, there'll always be the odd professional offense-taker; sookers gonna sook :-( But if Marty felt bruised by my comments then I apologise unreservedly. (Thommo's rockin' that bow-tie BTW)

Having said that, "frustrated" does not even begin to describe the gamut of emotions an auslander experiences when approaching the B-grade Lord of the Flies remake that is the W3C and IETF forums :-(

Any local bully with the conch can close down debate with the stroke of the keyboard, without having to justify or even explain their actions or rationale. Then, when I poke them in the ribs or tweak their noses, it's off to the Chairs and Tables to silence the impertinence.

Do you people ever have a good look at yourselves and the anachronistic pomposity of "The Chairs"? How often does new blood get introduced to these standards committees/projects? Is there anyone there over 40 or who started life cutting code?

Anyway, I'm sure you're as interested in my opinions on W3C/IETF as I am in the next time you'll wax lyrical about Moscow Morning Glory, so I'll stop. All I want is to be directed to a forum(s) where narcissism and the cult of personality come second to the facts/truth.

HTML5 desperately needs: -

1. Background GeoLocation. I, and others, have supported a viable solution via ServiceWorkers.
2. Javascript Client TOPIC subscription. Leverage existing, industry standard/strength, message providers.

There is nothing stopping (1), and (2) is only being handicapped by Mozilla's delusions of Message Service adequacy.

Who will listen to and debate these truths/facts? Please tell me where to go!

http://stackoverflow.com/questions/36587152/broadcasting-push-messages-to-javascript has been disappointing.

Cheers Dickie.