Hi all,
Last week the Push API editors (ATT, Telefónica) and other interested parties
(Mozilla, Google) met to progress this specification. It was a very productive
meeting in which great support was shown to this piece of work and consensus
was reached around many topics under discussion.
On Tue, Apr 29, 2014 at 10:00 AM, EDUARDO FULLEA CARRERA e...@tid.es wrote:
Promise unregister (); as a result of single registration allowed
Why does this have a return value?
Promiseenumeration hasPermission ();enumeration: Granted, Denied, Default
(or NeedToAsk)
I think this can be
-Message d'origine-
De : EDUARDO FULLEA CARRERA [mailto:e...@tid.es]
- App Server - Push Server protocol: Mozilla and Google to kick-off a
new draft at the IETF to standardize it.
Great, do we know where they plan to do this work ? and when a first draft will
be available ?
-
Thank you for these notes, Eduardo!
On Tue, Apr 29, 2014 at 11:21 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Tue, Apr 29, 2014 at 10:00 AM, EDUARDO FULLEA CARRERA e...@tid.es
wrote:
Promise unregister (); as a result of single registration allowed
Why does this have a return value?
On Tue, Apr 29, 2014 at 1:17 PM, Peter Beverloo bever...@google.com wrote:
Dropping a push registration has two aspects to it: (1) removing the mapping
between registration Id and the Service Worker to deliver it to on the
browser side, and (2) removing the registration on the push service.
Hi All,
The Tracking Protection WG asked WebApps to review their April 24 LCWD
of Tracking Preference Expression (DNT) so this is a Request for Comments:
http://www.w3.org/TR/2014/WD-tracking-dnt-20140424/
Individual WG members are encouraged to provide individual feedback.
If anyone in
On Tue, Apr 29, 2014 at 1:23 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Apr 29, 2014 at 1:17 PM, Peter Beverloo bever...@google.com
wrote:
Dropping a push registration has two aspects to it: (1) removing the
mapping
between registration Id and the Service Worker to deliver it to
1. This API needs to be on window.navigator. No further polluting of
the global object. (This is also how it appears to be implemented.)
2. It needs to return an string enum rather than a string. (With
values , yes, and no or some such.)
3. It should not return null. No need to vary type.
4. It
Both
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-javascript-api
and
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-ww-javascript-api
are inadequate. They need to allow for an asynchronous permission
check. In other words, return
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#processing-model
needs to be rephrased in terms defined by HTML. E.g. top-level origin
is the domain name of the top-level document origin of this DOM:
essentially the fully qualified domain name in the address bar. is
all kinds
On Tue, Apr 29, 2014 at 1:32 PM, Peter Beverloo bever...@google.com wrote:
On Tue, Apr 29, 2014 at 1:23 PM, Anne van Kesteren ann...@annevk.nl wrote:
Well yes, the question is why the application cares about garbage on
the push server. How would it handle the return value of unregister()
other
On Tue, Apr 29, 2014 at 2:04 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Apr 29, 2014 at 1:32 PM, Peter Beverloo bever...@google.com wrote:
It would still require another synchronous operation, which is unwanted for
browsers using multiple processes. Chrome uses a synchronous IPC
Hi Eduardo, all,
On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA e...@tid.es
wrote:
Hi all,
Last week the Push API editors (ATT, Telefónica) and other interested
parties (Mozilla, Google) met to progress this specification.
Just a gentle reminder that if you are having a
Hi Chaals, all,
It was not intended to be an official W3C meeting, but just an informal
discussion to feed the official standardization track, which AFAIK this mailing
list is part of. As you may note my previous email was not imposing any
agreement to the group but just proposing a set of
Hi All,
In addition to what Chaals said below, when folks meet to discuss
WebApps' specs, please do use the #webapps channel to record the
discussion (log is at [1]).
There are a number of cheat sheets re the IRC bots (f.ex. [2]) so
please do use those bots and if desired, we can easily
The only major issue that needs to be fixed in the Gamepad API spec
currently is the liveness of Gamepad objects[1].
Currently this is implemented differently in Firefox and Chrome--Firefox
uses live Gamepad objects, in that you can take the .gamepad property
from a GamepadEvent or a Gamepad from
From: Ted Mielczarek t...@mozilla.com
Does anyone have any feedback on which of these seems more natural? Is there
any precedent in the web platform to prefer one approach over the other?
If the snapshot approach is chosen, I think it would be best to rename the
Gamepad interface to
On Tue, Apr 29, 2014 at 4:24 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
If the snapshot approach is chosen, I think it would be best to rename the
Gamepad interface to GamepadSnapshot. Without that change, the live approach
seems a lot more natural.
DOM nodes are live. That is,
On Tue, 29 Apr 2014 16:02:43 +0200, EDUARDO FULLEA CARRERA e...@tid.es
wrote:
Hi Chaals, all,
Hi,
It was not intended to be an official W3C meeting, but just an informal
discussion to feed the official standardization track, which AFAIK this
mailing list is part of.
Right. But the
On 4/29/14, 11:32 AM, Anne van Kesteren wrote:
I think the main problem with making a Gamepad live is that the
lifetime of the object has to be lifetime of the associated global.
Otherwise GC can be observed through expandos.
For what it's worth, the way Gecko implements this is by setting up
Boris Zbarsky wrote:
For what it's worth, the way Gecko implements this is by setting up
that lifetime guarantee only when an expando is added to the object
(or some other things, like use as a WeakMap key, happen). Until then
we allow it to be GCed.
What do other engines do in general?
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
(Yes, I found https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.htmlby
googling. It's not what I need.)
On Tue, Apr 29, 2014 at 10:16 AM, Brendan Eich
I don't think that API design should be driven by implementation details,
but it may be useful to provide some background on Chrome's Gamepad
implementation here:
The current polling-only API Chrome uses is largely due to practicality
with the multiprocess architecture. The gamepad data is
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
The Gamepad API returns an array of Gamepad state objects when you call
getGamepads(), like so:
How would either make GC observable?
On Tue, Apr 29, 2014 at 10:45 AM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the
On Tue, Apr 29, 2014 at 10:39 AM, Ted Mielczarek t...@mozilla.com wrote:
The only major issue that needs to be fixed in the Gamepad API spec
currently is the liveness of Gamepad objects[1].
Currently this is implemented differently in Firefox and Chrome--Firefox
uses live Gamepad objects, in
On Tue, Apr 29, 2014 at 1:45 PM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
The Gamepad API
On 4/29/14, 1:46 PM, Mark S. Miller wrote:
How would either make GC observable?
Consider the following code:
navigator.getGamepads()[0].foo = 5;
var intervals = 0;
var id = setInterval(function() {
++intervals;
if (navigator.getGamepads()[0].foo != 5) {
alert(What happened
Hi,
Tim wrote:
Personally, the main thing I want to see is expose simpler and lower
level APIs. For my uses (backend to git server), the leveldb API is
plenty powerful[…] Would it make sense to standardize on a simpler set
of APIs similar to what levelDB offers and expose that in addition to
On 4/29/2014 1:34 PM, Brandon Jones wrote:
I don't think that API design should be driven by implementation
details, but it may be useful to provide some background on Chrome's
Gamepad implementation here:
The current polling-only API Chrome uses is largely due to
practicality with the
On Tue, Apr 29, 2014 at 11:07 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/29/14, 1:46 PM, Mark S. Miller wrote:
How would either make GC observable?
Consider the following code:
navigator.getGamepads()[0].foo = 5;
var intervals = 0;
var id = setInterval(function() {
I think both semantics are workable. I'd likely prefer the gamepad state to
be immutable from JS, because assigning state there is smelly. I'd also
prefer the option that incurs less GC overhead if possible. Beyond that, I
just think the implementations should be semantically and symbolically
On Tue, Apr 29, 2014 at 3:27 PM, Florian Bösch pya...@gmail.com wrote:
I think both semantics are workable. I'd likely prefer the gamepad state
to be immutable from JS, because assigning state there is smelly.
Yes, there should be no way for user code to directly alter the value of
properties
On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA e...@tid.es wrote:
Hi all,
Last week the Push API editors (ATT, Telefónica) and other interested
parties (Mozilla, Google) met to progress this specification. It was a very
productive meeting in which great support was shown to this
Gamepad objects should definitely be a snapshot. Otherwise, change events
could only expose the most recent state of the gamepad. For example, if
the user presses a button and then releases it very quickly (before the
down press gets handled by script), and you fire two change events, the
script
If it were my call I'd vote for gamepad objects being snapshots simply
because it will add some additional overhead to make them live and it
avoid concerns about observing GC, but I don't really object to either
design.
Anne mentioned the observable GC concern, he said the spec should
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25467
Morrita Hajime morr...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470
Bug 25470 depends on bug 25467, which changed state.
Bug 25467 Summary: [imports]: Dynanically added imports should block following
imports.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25467
What|Removed
On Tuesday, April 29, 2014 5:46 AM, Anne van Kesteren wrote:
Both http://www.w3.org/2011/tracking-protection/drafts/tracking-
dnt.html#exceptions-javascript-api
and http://www.w3.org/2011/tracking-protection/drafts/tracking-
dnt.html#exceptions-ww-javascript-api
are inadequate. They need to
On Tue Apr 29 2014 at 4:28:31 PM, Glenn Maynard gl...@zewt.org wrote:
(That said, I'm confused--where's the event to tell the user that the
gamepad has changed? Surely this API doesn't require the developer to
poll, which would lose inputs at the slightest GC skip and could never give
high
On Tue, Apr 29, 2014 at 6:42 PM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 4:28:31 PM, Glenn Maynard gl...@zewt.org wrote:
(That said, I'm confused--where's the event to tell the user that the
gamepad has changed? Surely this API doesn't require the developer to
poll,
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example, if the user presses a button and then releases it very
quickly (before the down press gets handled by
On 4/29/2014 7:35 PM, Oren Freiberg wrote:
Originally I was leaning towards live model but I am now leaning towards a
snapshot model being the better option. We also found that there was added
overhead with making the values live. Having had a few developers play around
with both the idea
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change events
could only expose the most recent state of the gamepad. For example, if
the user presses a button and then releases it very quickly (before the
down
On Tue, Apr 29, 2014 at 9:38 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example,
On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek t...@mozilla.com wrote:
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example, if the user presses a button
46 matches
Mail list logo
