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<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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
