On Wed, May 6, 2015 at 6:25 AM, Anne van Kesteren wrote:
> On Wed, May 6, 2015 at 12:32 AM, Mike West wrote:
> > I agree with Jonas. Extending the permission API to give developers a
> single
> > place to check with a single consistent style seems like the right way to
> > go.
>
> Yet others at
Looks good to me. While we are continuing work on data payload encryption
and alignment with the IETF Web Push Protocol, it makes sense to refresh
the WD snapshot.
Regards,
Michael
On Mon, Apr 27, 2015 at 2:39 PM, Arthur Barstow
wrote:
> This is an announcement of the intent to publish a new
I filed an issue regarding the term webapp:
https://github.com/w3c/push-api/issues/77
/m
On Thu, Oct 9, 2014 at 7:52 PM, Michael van Ouwerkerk <
mvanouwerk...@google.com> wrote:
> Indeed, the spec is currently inconsistent about registrations. The
> current intention is to
Indeed, the spec is currently inconsistent about registrations. The current
intention is to have one per ServiceWorkerRegistration (i.e. per service
worker). See for more details and discussion:
https://github.com/w3c/push-api/issues/71
The term webapp does seem a bit odd to me. It's really just a
On Wed, Sep 24, 2014 at 3:20 PM, Arthur Barstow
wrote:
> [ Bcc webp...@ietf.org ]
>
> Hi All,
>
> I recall the IETF's intent to create a web-based push notifications
> protocol standard was previously announced on this list. Please note the
> draft charter for this WG explicitly mentions WebApps:
Thomson wrote:
> On 13 May 2014 06:39, Michael van Ouwerkerk
> wrote:
> > Martin, in Chrome we use registrationId and endpoint for distinct
> purposes.
> > The endpoint is the push server url to which the app server posts new
> > messages. The registrationId identifie
Martin, in Chrome we use registrationId and endpoint for distinct purposes.
The endpoint is the push server url to which the app server posts new
messages. The registrationId identifies the correct {device, user, page} to
which the message will be sent.
Please see this diagram for the full picture
Thanks for your detailed reply.
/m
On Thu, Mar 20, 2014 at 7:35 PM, Jonas Sicking wrote:
> On Thu, Mar 20, 2014 at 8:19 AM, Michael van Ouwerkerk
> wrote:
> > An example call might look like this:
> > navigator.push.register({
> > gcmSenderId: 'some va
ext by normative vs.
> informative. How would implementations differ if it were normative vs. if
> it were informative?
> --------------
> From: Michael van Ouwerkerk
> Sent: 3/20/2014 11:46
> To: Domenic Denicola
> Cc: public-webapps
> Subject: Re:
> From: Michael van Ouwerkerk
>
> > Ah I didn't know it has no effect on return values. Why not?
>
> Well, I believe it's the same with all WebIDL method return values. If you
> return something that doesn't match the declared return value, that's a
> sp
Ah I didn't know it has no effect on return values. Why not?
/m
On Thu, Mar 20, 2014 at 3:31 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: Michael van Ouwerkerk
>
> > It reads much better and the prose can be simplified.
>
> I am curious ab
In WebIDL we can now use parameterized Promise types:
http://heycam.github.io/webidl/#idl-promise
My suggestion is that we make some minor changes in the Push API spec to
take advantage of this. It reads much better and the prose can be
simplified.
The following promise types:
interface PushMana
To prevent abuse, many platforms require vendor specific registration
details for interacting with their push messaging systems. This allows e.g.
for banning spammers.
On Android, Google Cloud Messaging (GCM) is the canonical push messaging
system. Client registration requires passing a sender id
In Blink/Chrome we are looking into the Push API. We intend to use Service
Workers as an alternative for System Messages. The idea is to fire an event
in the SW when a push message is received. This has a big advantage: waking
up a SW should be much faster than loading the whole document.
Regards,
I think that's a great suggestion Jeffrey.
Specifically, I would like to avoid confusing concepts and terminology in
the Push API with those in Web Notifications:
http://www.w3.org/TR/notifications/
This is important because these two APIs are often discussed together: an
app might display a noti
15 matches
Mail list logo
