On Nov 11, 2011, at 00:23 , Tab Atkins Jr. wrote:
> On Thu, Nov 10, 2011 at 3:12 PM, Scott Graham <scottmg@google.com> wrote:
>> My initial thought would be that the same Vibration Interface would
>> also appear on Gamepad, so a connected gamepad would have
>> .vibrate(time) and .vibrate([pattern]).
>
> This seems reasonable. One could even have a device which can,
> itself, vibrate (controlled via the navigator interface) and which can
> have gamepads hooked up to it which can vibrate (controlled via the
> gamepad interface).
It can get more interesting still: gamepads (as well as some phones) may have multiple vibrators. It is very much conceivable that at some point we could have an API that would return multiple vibrators that could be controlled individually (handling such advanced cases however is a clear non-goal for our v1).
>> As the DAP is set up to handle things related to vibration, could the
>> vibration spec simply add a reference to the Gamepad spec, and make
>> the addition of having Gamepad implement Vibration? (as well as
>> Navigator of course)
>
> Yes, that sort of reference is acceptable.
Acceptable, yes, but I think it would be backwards :) Anssi has recently modified the Vibration API so that the Vibration interface is reusable. It shouldn't IMHO be up to this spec to define every location in which vibration should be used. Instead, I would recommend that the specification defining Gamepad simply reference Vibration and state that "Gamepad implements Vibration".
I realise that according to this reasoning we could do the same with "Navigator", but Navigator is special (and not new), and we need at least one concrete binding to make the spec usable.
Would that be agreeable to the Gamepad folks? We're more than happy to coordinate on feedback, use cases, and all so please don't take this as push-back at all â€” I just feel it would be weird for the Vibration spec to define what happens on Gamepad, whereas it would feel natural for Gamepad to reuse Vibration (especially since it was modified to make that possible).
--
Robin Berjon - http://berjon.com/ - @robinberjon