Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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: -
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?
From IETF mailing lists: -
Richard Maher email@example.com
to Benjamin, Kit, jr, webpush
Yes, a living and evolving document. Let's not seek to censor the discussion or spit the dummy.
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?
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 :-(
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).
This mailing list is to discuss the IETF WebPush protocol, while some
For WebPush, thats the primary intention.
GCM can, WebPush cannot. What you're referring to has been proposed as
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.
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.
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 :-(
Did you miss this bit: -
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.
“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!
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.
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.”
Great minds (not just Google): -
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.
Engage audiences directly or all-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!
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: -
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!