[webkit-dev] Adding the Vibration API to WebCore

[Soo-Hyun Choi]

It seems that a WebKit reviewer, Hajime Morrita, created another bug
(https://bugs.webkit.org/show_bug.cgi?id=78085) related to this patch.
As said in the bug #78085, it would be more preferred way not to
access Page and PageClient directly.

The author of this bug might want to check them before asking r+.

Kind regards,
Soo-Hyun


On Thu, Feb 2, 2012 at 03:11, Soo-Hyun Choi <s.choi at hackerslab.eu> wrote:
>
>
> On 2/2/12 1:01 AM, Robin Berjon wrote:
>> On Feb 1, 2012, at 11:02 , Soo-Hyun Choi wrote:
>>> On 2/1/12 3:00 AM, Simon Fraser wrote:
>>>> My comment was actually meant to be somewhat facetious, and intended to reflect how arbitrary the new APIs are. Why support GamePad input, and not TV remote control input? Why only deal with vibration on a mobile device, and not other kinds of hardware feedback? I don't think they are good APIs.
>>>
>>> Well, you are right in a sense that one may like to see some form of
>>> unified API that can represent various hardware feedback, but I guess
>>> that will take ages to be finalised at the W3C's point of view.
>>
>> If you're talking about full haptic feedback support, it's not just standards that's the bottleneck (though it would indeed take a while) but also the fact that it's a fast-moving innovation area that doesn't seem ripe for standardisation just yet. Also, too few devices are currently equipped with what it takes to make this interesting.
>
> Absolutely - that's why I have said that this patch shouldn't be
> questioned by the W3C's standard perspective at the particular moment.
> As far as I understand, Simon's original suggestion was to take these
> sort of APIs to W3C and come back later, which doesn't seem to be quite
> reasonable per the reason we discussed.
>
>>
>> I expect that if this becomes a feature of devices that customers come to expect and that is commonly put to good use, then there will be an API for it. But I wouldn't hold my breath at this point.
>>
>>> In this respect, I'd like to assume that they are not simply arbitrary
>>> APIs, but interesting ones that might be emerged into some other form(s)
>>> later as W3C elaborates the spec standards.
>>
>> Yes, and not only are they not arbitrary but they are (hopefully) made to be sufficiently orthogonal so as to be used together properly. If you search through (http://lists.w3.org/Archives/Public/public-device-apis/) you'll find a few occurrences of collaboration with the Gamepad team that ensure that you can call navigator.vibrate() to get your primary device to vibrate, but also gamepad.vibrate() with everything working the same as soon as you have a handle on a gamepad.
>>
>
> Fully agreed - I didn't particularly insist it to be integrated in a
> single abstract-level API that can be derived on usage basis. As you've
> mentioned, I agree they can be orthogonal in terms of
> usage/functionality, so it may not necessary at all to make them such way.
>
>
> The whole point I am making here is that it looks quite worthwhile to
> enable this vibration API in the WebKit trunk.
>
>
> Kind regards,
> Soo-Hyun
>