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

[bugzilla-daemon at webkit.org]

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





--- Comment #27 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2012-07-17 11:16:30 PST ---
(In reply to comment #26)
> (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.

My point was that you could break all of these up into two pieces:

1)  Do I have permission to request [device capability]?

2)  Request [device capability].

These only need to be coupled in cases where we don't trust the renderer to prefix #2 with #1.  My understanding is that we aren't trying to prevent a rogue renderer from abusing #2.  Or, am I mistaken?


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

In general, I think that sort of encapsulation just adds overhead.  We don't need two IPC systems or nested IPC systems in Chrome.  The WebKit API is supposed to be a thin wrapper around WebCore.  There's not much reason to minimize the number of WebKit API methods in other words.

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