> (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 -> GeolocationSe
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 i
> 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,
presumabl
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
> provi
On Dec 10, 2010, at 6:45 AM, John Knottenbelt 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 readable
> because the
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 n
6 matches
Mail list logo
