> 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?
That would need to be assessed on a case by case basis, as it depends on the specific requirements an extension has.
That said, the group did not design the API with any specific extension mechanism in mind, because the intersection of the major platforms is pretty much what we have now. We also thought we’ll cross that extensibility bridge when we get there.
Should we need to extend the API in the future, we could use method overloading, or a separate method, for example, depending on the requirements.
Next message: Frederick.Hirsch@nokia.com: "Re: Network info API"
Previous message: Frederick.Hirsch@nokia.com: "[admin] View of Web Platform Tests contributions per Working Group"
In reply to: Iain Dawson: "Re: Implied Pairs in the Vibration API"