atom feed12 messages in org.webkit.lists.webkit-devRe: [webkit-dev] Adding the Vibration...
FromSent OnAttachments
권기홍Nov 10, 2011 5:57 am 
Adam BarthNov 10, 2011 9:02 am 
Simon FraserNov 10, 2011 2:37 pm 
Hajime MorritaJan 29, 2012 11:14 pm 
권기홍Jan 31, 2012 4:50 am 
Simon FraserJan 31, 2012 10:00 am 
Wonsuk LeeJan 31, 2012 11:01 am 
Robin BerjonJan 31, 2012 11:55 am 
Soo-Hyun ChoiFeb 1, 2012 2:02 am 
Robin BerjonFeb 1, 2012 8:01 am 
Soo-Hyun ChoiFeb 1, 2012 10:11 am 
Soo-Hyun ChoiFeb 8, 2012 4:08 am 
Subject:Re: [webkit-dev] Adding the Vibration API to WebCore
From:Soo-Hyun Choi (s.c@hackerslab.eu)
Date:Feb 8, 2012 4:08:19 am
List:org.webkit.lists.webkit-dev

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 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