[webkit-dev] Upstreaming Support for W3C Sensor API
chuck at jumis.com
Mon Mar 19 14:25:28 PDT 2012
Maciej, I've been trying to find a home for Ink data for some time.
The one inroad I've made was to make the case in the touch events 2
Is that what I should move forward with, with Ink?
I've been following the Sensor API because the structure works for the
raw data of a pen, monitoring pen pressure, tilt and rotation,
resolution and other items,
to the standard serialization format now recommended by the W3C:
Raw sensor data:
The whole of the Sensor API can be serialized without losing information
or "breaking" the file; it allows arbitrary units in addition to the base:
The Gamepad API itself has shown "resolution" issues:
Do we want to move forward with device-specific APIs, such as "Gamepad"
and "Touch Events 2", or do we want to have a more general mechanism?
The Sensor API is a more low level API than the gloss and sheen of Touch
2 or Gamepad.
When you've got a high fidelity sensor, such as a Wacom pen, those
things can sure burst a whole lot of information. Wikipedia says "up to
200 times per second".
That's where the Sensor API could work well for a very reasonable use
case (high fidelity ink).
On 3/16/2012 3:26 PM, Maciej Stachowiak wrote:
> I think this feature is pretty far out relative to WebKit project goals, even independent of spec maturity level.
> We've had controversy (though ultimately tentative agreement on adding) APIs for hardware found in some but not all classes of mainstream hardware that runs a browser. For example, Vibration API was pretty specific to the phone. Gamepad API seems specific to game consoles or those relatively rate PCs that have a game pad attached.
> The types of sensors in this API (Temperature, Air Pressure, Humidity, Magnetic Field Strength...) strike me as not common I/O devices on any mainstream class of hardware. Therefore I would class this whole feature area as experimental and not in line with WebKit project goals.
> Therefore, I think this work is not appropriate for the WebKit repository at this time, even as a WebCore Module. Of course, implementing the feature outside the main repository, e.g. via GitHub, is ok, and may be an opportunity to demonstrate its general usefulness.
> On Mar 16, 2012, at 2:15 PM, Adam Barth wrote:
>> Historically, the WebKit project hasn't had the warmest relationship
>> with the DAP working group, and we've tended to be conservative about
>> which DAP APIs we merge into trunk. The Sensor API appears to be
>> fairly early in its lifecycle. As far as I can tell, it hasn't even
>> reached FPWD, which means, among other things, that the W3C patent
>> process hasn't started. These factors lead me to think that we should
>> wait a bit before landing the feature in trunk.
>> You might consider implementing this feature as a WebCore Module
>> <https://trac.webkit.org/wiki/Modules>. If you go that route, the
>> implementation should be fairly loosely coupled with the rest of
>> WebCore, which means implementing the feature first on GitHub (a la
>> <https://trac.webkit.org/wiki/UsingGitHub>) might be a good choice.
>> This approach will give you a chance to experiment with an
>> implementation and receive feedback from the WebKit community without
>> being blocked on merging your feature into trunk.
>> 2012/3/16 Adam Barth<abarth at webkit.org>:
>>> The specification appears to be here:
>>> Has this specification reached FPWD yet? http://www.w3.org/TR/sensor/
>>> returns a 404.
>>> 2012/3/16 Dominik Röttsches<dominik.rottsches at linux.intel.com>:
>>>> Hello webkit-dev,
>>>> We would like to upstream our implementation of W3C Sensor API .
>>>> As we are aware that this is a young specification, we propose to have it
>>>> default #ifdef-disabled.
>>>> However, we believe it could be useful for certain ports or useful for being
>>>> accessed by Chrome extensions.
>>>> Your feedback is welcome.
>>>> For reference, we created meta bug
>>>> Dominik Röttsches
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev