Re: [webkit-dev] Upstreaming Support for W3C Sensor API
Maciej, Adam, On 03/17/2012 12:26 AM, Maciej Stachowiak wrote: 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. thank you for your suggestions and feedback. Going the GitHub route is an option for us, we'll keep everyone informed on tracking bug 81352. Regards, Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Upstreaming Support for W3C Sensor API
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 Barthaba...@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öttschesdominik.rottsc...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Upstreaming Support for W3C Sensor API
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Upstreaming Support for W3C Sensor API
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.rottsc...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Upstreaming Support for W3C Sensor API
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 aba...@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.rottsc...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Upstreaming Support for W3C Sensor API
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 aba...@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.rottsc...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
