[webkit-dev] Client-based Geolocation

[Maciej Stachowiak]

On Dec 10, 2010, at 6:45 AM, John Knottenbelt wrote:

> I've been working on getting Chromium's WebKit layer to support client-based Geolocation. This means that a class in the Chromium WebKit layer implements the WebCore interface GeolocationClient, and an instance of this class is provided to the Page constructor (by means of PageClients). This is a neat way of keeping the platform specific code in the WebKit layer (rather than in WebCore, where the existing GeolocationService and platform code is). The design of client-based geolocation feels very clean and I think it is easier to understand as it follows a similar pattern to other existing client-based designs (e.g. speech, device orientation, device motion).
> 
> It would be great if, ultimately, we could remove the non-client-based geolocation code from WebCore (I already have plans to do this for Chromium's WebKit layer). Such a removal would make the WebCore code more readable because the #if ENABLE(CLIENT_BASED_GEOLOCATION) preprocessor directives would go away, more understandable because there would be less code, and more maintainable because we would only need to fix bugs in one code path, rather than two. 
> 
> It seems that Android, Qt and GTK currently implement the non-client-based design. Is anybody working, or interested in working, on migrating these platforms to the client-based design? 

On the one hand, getting rid of ifdefs is good. On the other hand, it seems to me there are some downsides to moving ports over to the client-based approach:

(1) Adds a level of indirection that may not be necessary in these cases.
(2) Harder to find the back end code, since the common pattern is to have platform-specific implementations in WebCore/platform
(3) There may not be a one-to-one mapping between back-end implementations and WebKit public APIs.

#3 in particular seems like a strike against moving code to the WebKit layer if it is applicable in this case.

The approach I'd rather see for features like this is to have the back end implementations in WebCore, and give ports that need to add cross-process proxying (such as Chromium or WebKit2) a way to hook that up.

Regards,
Maciej