Re: [gamepad] Polling access point

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.leithead@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:* scottmg@google.com [mailto:scottmg@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****
>