[webkit-dev] Upstreaming Support for W3C Sensor API

[Charles Pritchard]

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 
proposal:
https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html

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:
http://www.wacomeng.com/web/WebPluginReleaseNotes.htm#_Toc293867182
Sensor API:
http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
Serialization format:
http://www.w3.org/TR/InkML/

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:
http://www.w3.org/TR/InkML/#units

The Gamepad API itself has shown "resolution" issues:
http://code.google.com/p/chromium/issues/detail?id=79050

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

-Charles


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.
>
> Regards,
> Maciej
>
> 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.
>>
>> Adam
>>
>>
>> 2012/3/16 Adam Barth<abarth at webkit.org>:
>>> The specification appears to be here:
>>> http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
>>>
>>> Has this specification reached FPWD yet?  http://www.w3.org/TR/sensor/
>>> returns a 404.
>>>
>>> Adam
>>>
>>>
>>> 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 [1].
>>>>
>>>> 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
>>>> https://bugs.webkit.org/show_bug.cgi?id=81352
>>>>
>>>> Regards,
>>>>
>>>> Dominik Röttsches
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev