On Mon, Nov 14, 2011 at 3:23 AM, Robin Berjon <robin@berjon.com> wrote:
> 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".
>
That seems fine to me, I'm not bothered which way the reference goes.
Either way, we'll just need to make sure to coordinate future changes so
that the two specs can continue to integrate cleanly.
Regards,
scott