Thanks Travis, that seems like the "least surprising" solution. I guess getGamepads() would be the preferred name by analog with getUserMedia() then.
On Thu, Jul 26, 2012 at 4:10 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Going to a function-based design is typically preferable (especially to > making an attribute non-enumerable). This is the approach taken by > getUserMedia.**** > > ** ** > > *From:* scot...@google.com [mailto:scot...@google.com] *On Behalf Of *Scott > Graham > *Sent:* Thursday, July 26, 2012 4:02 PM > *To:* public-webapps@w3.org > *Cc:* Ted Mielczarek > *Subject:* [gamepad] Polling access point**** > > ** ** > > Hi,**** > > ** ** > > It looks like the access point for the polling part of the API > (navigator.gamepads[]) is not a good idea.**** > > ** ** > > Based on a prototype implementation, pages seem to have a tendency to > enumerate Navigator. When the .gamepads[] attribute is accessed, it causes > possibly expensive background resources to be created to access hardware, > even though the content is not really interested in reading data from the > hardware.**** > > ** ** > > Possible solutions:**** > > - change from navigator.gamepads[] to navigator.gamepads() (or > navigator.getGamepads()) to be more explicit about when the API is actually > being used**** > > - require something to activate the API (meta tag, calling some sort of > "start" function)**** > > - require registering for at least one gamepad-related event before data > is provided in gamepads[].**** > > - make .gamepads[] non-enumerable**** > > ** ** > > Any thoughts or other suggestions?**** > > ** ** > > Thanks,**** > > scott**** >