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
Hi,
I would love to gather the opinion of public-webapps on a discussion
Hixie and I had for two different APIs recently: if an array |foo| can
change, should the change event be fired on its parent or the window
(its grandparent)? The two cases we discussed with Hixie were
navigator.languages
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
From: Michael van Ouwerkerk mvanouwerk...@google.com
It reads much better and the prose can be simplified.
I am curious about the prose simplifications you mention? From talking to
heycam, the value in the angle-brackets has no impact when used on the return
type of a method, so I can't
On Fri, 21 Mar 2014, Mounir Lamouri wrote:
I would love to gather the opinion of public-webapps on a discussion
Hixie and I had for two different APIs recently: if an array |foo| can
change, should the change event be fired on its parent or the window
(its grandparent)? The two cases we
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
From: 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
So it is not normative? It seems it would be very informative though, so
still worth adding to the spec. But it seems it would be even better if it
was changed to be normative.
Thanks,
Michael
On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From:
I am not sure what you mean in this context by normative vs. informative. How
would implementations differ if it were normative vs. if it were informative?
From: Michael van Ouwerkerkmailto:mvanouwerk...@google.com
Sent: 3/20/2014 11:46
To: Domenic
Well, I interpreted your comment that way (it has no impact on anything).
Maybe normative vs informative is not what you meant though?
/m
On Thu, Mar 20, 2014 at 3:56 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I am not sure what you mean in this context by normative vs.
I still don't understand what you mean by normative vs. informative in this
context, so I can't say whether my original statement bolsters one or the other
:P
How would implementations differ if it were normative vs. if it were
informative?
From: Michael van
On Thu, Mar 20, 2014 at 8:33 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 21 Mar 2014, Mounir Lamouri wrote:
I would love to gather the opinion of public-webapps on a discussion
Hixie and I had for two different APIs recently: if an array |foo| can
change, should the change event be fired on
I agree that there is significant readability value to the consumer of a
WebIDL-based API spec if the return types of Promise-returning APIs are
captured in the IDL. For the same reason that documenting return types is
valuable to readability even though not enforced in the JavaScript
On 3/20/14 11:39 AM, Domenic Denicola wrote:
If you return something that doesn't match the declared return value, that's a
spec bug, but it has no impact on anything.
True, though the spec bug may make the spec not implementable (e.g. in a
UA that autogenerates code from the IDL for a
On 3/20/14 11:46 AM, Michael van Ouwerkerk wrote:
So it is not normative? It seems it would be very informative though, so
still worth adding to the spec. But it seems it would be even better if
it was changed to be normative.
It's normative in the sense that the implementation of the method
On Fri, 21 Mar 2014, at 2:28, Michael van Ouwerkerk wrote:
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
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: 'some other value'
});
Let me play devil's advocate a bit.
We have already given up on having the
On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
Agreed. The exact target isn't very important here, and so being
consistent with legacy event firing for the same system is probably
a good idea.
Agree. Let's go with consistency, even though it feels a bit
On Wed, Mar 19, 2014 at 8:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
This is because we have been bit several times by having code from
security context A (in our case code from chrome://) receive a URL
from code from security context B. A would then load that URL. This
way B can trick A
19 matches
Mail list logo
