- From: Justin Lebar <jlebar@mozilla.com>
- Date: Mon, 7 Nov 2011 16:44:03 -0500
- To: João Eiras <joaoe@opera.com>
- Cc: public-device-apis@w3.org
> Having a Vibrator interface, which then Gamepad and Navigator implement, > hence being reusable. > > So we then get navigator.vibrate() and gamepad.vibrate(). Same API, same > behavior. Ah, I see. That sounds fine to me! Thanks for clarifying. -Justin On Mon, Nov 7, 2011 at 4:37 PM, João Eiras <joaoe@opera.com> wrote: > >> On Mon, Nov 7, 2011 at 1:03 PM, João Eiras <joaoe@opera.com> wrote: >>> >>> Hi. >>> >>> The vibrator API's WebIDL [1] should not expose the two methods directly >>> in >>> the navigator object. >>> >>> Instead it should be in a separate interface, so it can be implemented as >>> a >>> singleton API in the window/navigator object for a mobile device like a >>> phone, or can be implemented on top of the gamepad object whenever the >>> gamepad APIs moves forward, to feed vibration back to the controller. >>> >> On Mon, 07 Nov 2011 19:45:24 +0100, Justin Lebar <jlebar@mozilla.com> >> wrote: >> >> As in navigator.vibrator.vibrate()? >> >> I don't understand why this is better than navigator.vibrate(). Why >> can't the gamepad API expose a method which matches >> navigator.vibrate()? >> >> -Justin >> > > No. > > Having a Vibrator interface, which then Gamepad and Navigator implement, > hence being reusable. > > So we then get navigator.vibrate() and gamepad.vibrate(). Same API, same > behavior. > > The gamepad spec can later refer to the Vibrator interface. The Vibrator > spec itself does not need to. > > Hope I was clearer now. > >
Received on Monday, 7 November 2011 21:44:51 UTC