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

Wed Jul 18 10:14:09 PDT 2012

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

--- Comment #28 from Amy Ousterhout <aousterh at chromium.org>  2012-07-18 10:14:06 PST ---
(In reply to comment #27)
> (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?

That’s correct - we do trust the renderer to prefix #2 with #1, so the two don’t need to be coupled. However, decoupling them would require WebCore to maintain information about the embedder's state, which is a layering violation. For example, in the current design, if the embedder wants to turn off GPS because a tab is in the background, or if the embedder wants to change its data source from GPS to network location, it can change those properties directly without interacting with WebCore. If Webcore instead were to obtain device data through the platform layer, the embedder would have to pass this information down through WebKit into WebCore (something along the lines of device_orientation_controller->suspend(), which would then eventually call platform_impl->suspend(), and similar for changing other properties). When something similar was attempted with Geolocation, the feedback was that we shouldn't clutter WebCore with stuff like that if the embedder can handle it instead.

In addition, it's not possible for WebCore to prefix #2 with #1 every time it obtains device data, since an embedder's preferences about how to obtain data could change at any time, and the arrival of device data is event-driven.

What would be the advantages to decoupling them (besides adhering to the policy mentioned above)?

@fishd, hans, steveblock: Can we set up a VC to discuss this?  I don't think that we're completely understanding each others' arguments, and it would be helpful to have this discussion in one sitting instead of strung-out over multiple days.

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