[webkit-dev] Always enabling ENABLE(CLIENT_BASED_GEOLOCATION) ?
abarth at webkit.org
Thu Feb 16 17:23:39 PST 2012
On Bug 78853, Benjamin Poulain <benjamin at webkit.org> wrote:
>>>> We still use that code, please wait a bit before removing it.
>>> Which port uses the code?
> iOS. We have reasons to keep maintaining this code at the moment. We can remove that later.
> Is this blocking other architectural changes?
This came up because I was analyzing the Geolocation code as part of
working on <https://bugs.webkit.org/show_bug.cgi?id=78860>. This
issue also came up in June 2010
<https://bugs.webkit.org/show_bug.cgi?id=40373>, at which port Steve
The maintenance burden of two implementations is becoming increasingly
high, particularly in the light of possible refactorings to solve b/f
cache problems, discussed in Bug 40162
The client-based implementation seems to be the correct approach as it
avoids the layering violations of the initial approach, so we should
switch all ports to use the client-based implementation.
In a series of bugs blocking Bug 40373, Steve Block worked with
maintainers of various ports to move all the WebKit ports to the new
Historically, the WebKit project hasn't let forks of WebKit constrain
the development of trunk. As far as I can tell, the iOS port is not
part of trunk, and, if the iOS port were to merge with trunk, it seems
likely that it would need to adopt the same architecture used by
On Thu, Feb 16, 2012 at 4:02 PM, Adam Barth <abarth at webkit.org> wrote:
> I've posted a patch in https://bugs.webkit.org/show_bug.cgi?id=78853 .
> On Thu, Feb 16, 2012 at 2:40 PM, Adam Barth <abarth at webkit.org> wrote:
>> Is there anyone who uses Geolocation and doesn't enable
>> ENABLE(CLIENT_BASED_GEOLOCATION) ? A quick grep through the build
>> systems seems to indicate that everyone enables it. Should we remove
>> the non-Client-based code path?
>> See https://bugs.webkit.org/show_bug.cgi?id=40373 for context. (All
>> of its dependencies are marked as FIXED.)
More information about the webkit-dev