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 art.bars...@gmail.com
wrote:
This is an announcement of the
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 have one per
On Wed, Sep 24, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com
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
Thomson martin.thom...@gmail.comwrote:
On 13 May 2014 06:39, Michael van Ouwerkerk mvanouwerk...@google.com
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
for your detailed reply.
/m
On Thu, Mar 20, 2014 at 7:35 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 20, 2014 at 8:19 AM, Michael van Ouwerkerk
mvanouwerk...@google.com wrote:
An example call might look like this:
navigator.push.register({
gcmSenderId: 'some value',
apnsPushId
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 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
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 mvanouwerk...@google.com
It reads much better and the prose can be simplified.
I am curious about the prose
: Michael van Ouwerkerk mvanouwerk...@google.com
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
spec bug, but it has no impact on anything
.
informative. How would implementations differ if it were normative vs. if
it were informative?
--
From: Michael van Ouwerkerk mvanouwerk...@google.com
Sent: 3/20/2014 11:46
To: Domenic Denicola dome...@domenicdenicola.com
Cc: public-webapps public-webapps@w3.org
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.
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
12 matches
Mail list logo
