Re: Implied Pairs in the Vibration API

Thanks for the detailed response. Third-party libraries totally could build
nice wrappers for people wanting to do complicated stuff (or for
themselves), and you're right, for most cases that would be fine.

Multi-vibration devices was simply the only other extension that came to
mind, but I'm not convinced it'd be the only one. For instance, with
lateral vibration motors, it might be reasonable to expect people to want
to manipulate both frequency and intensity of vibration at some point.

Can you describe a way future extensions to the API could be implemented
such that backwards compatibility with sensible fallbacks would be
reasonably trivial?