(1) Adds a level of indirection that may not be necessary in these cases.
It's true, there's now one more level of indirection. The
non-client-based implementation uses Geolocation -
GeolocationServiceFoo. The client-based implementation uses
Geolocation - GeolocationController -
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:
The motivation is much more than removing ifdefs. The original
Geolocation implementation was provided in WebCore/platform,
presumably
On Dec 14, 2010, at 4:57 AM, Steve Block wrote:
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:
The motivation is much more than removing ifdefs. The original
Geolocation
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
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
On Dec 10, 2010, at 6:45 AM, John Knottenbelt jknot...@chromium.org wrote:
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
6 matches
Mail list logo
