[Webkit-unassigned] [Bug 89197] [Chromium] Implements DeviceMotion

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=89197





--- Comment #26 from Amy Ousterhout <aousterh at chromium.org>  2012-07-17 08:21:54 PST ---
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > I will do a more thorough review shortly, but just a comment on the design.  I feel like the design for "device orientation" may not have been done correctly.  Put simply, things that are properties of the device instead of properties of the WebView should be accessed through the platform instead through the WebView.  Is device orientation really something WebView-specific?  Maybe it is possible to have two monitors that are oriented differently?  Hmm...
> > 
> > Geolocation was originally accessed through the platform, but was eventually switched to the WebView, because the embedder needed to have close control over it (to handle permissions, to suspend it to save power, to control the polling frequency, etc.). It makes sense for DeviceOrientation and DeviceMotion to be implemented similarly, so that the embedder can have close control over them.
> > 
> > This e-mail thread (https://lists.webkit.org/pipermail/webkit-dev/2010-December/015313.html) discusses the pros and cons of switching Geolocation from the platform-based approach to the client-based approach.
> 
> Our standard design approach is to have policy APIs at the WebView layer combined with functional APIs at the platform layer.  I think Geolocation would likely benefit from this separation of concerns too.

I agree with the principle of "policy APIs at the WebView layer combined with functional APIs at the platform layer". However, for Geolocation, Device Orientation, and Device Motion, there isn't really a functional component - all three require policy decisions. Geolocation involves policy decisions for user permissions and to determine where to obtain data from (GPS, network location, etc.). All three kinds of data involve policy decisions regarding polling frequency and suspension when a tab is in the background to reduce power consumption.  Implementing these APIs in the platform layer would require a layering violation in order to obtain the necessary policy information from the embedder.

In the long run, if there end up being several types of device data that similarly require policy decisions, they can be consolidated into one pathway through WebKit and demultiplexed in WebCore, so in case you're worried about there being a large number of these APIs in the future, that can be avoided.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.