Re: [Webpush] Polling to adopt VAPID draft

[Richard Maher <[e-mail]>]

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 <[e-mail]>
wrote:

> On Tue, Apr 5, 2016 at 7:45 PM, Richard Maher <[e-mail]>
> 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
>