[Webkit-unassigned] [Bug 36315] Remove obsolete Geolocation::m_currentPosition

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 21 11:54:29 PDT 2010


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





--- Comment #10 from Steve Block <steveblock at google.com>  2010-04-21 11:54:28 PST ---
> > Looks good to me otherwise. To further clarify the code, we could remove the
> > Geoposition argument from positionChanged() and hence setPosition(). Instead,
> > positionChanged() would just call m_service->lastPosition() directly. This
> > would also bring the client-based code path in line with the existing code
> > path. 
> 
> Hmm, I don't quite understood this bit: setPosition is part of the public API,
> I'm not sure if I can just remove GeolocationPosition (not Geoposition) from
> it. If you're saying to remove only from the call to positionChanged(), that
> would require pushing up
> "m_positionCache->setCachedPosition(newPosition.get());" to the two APIs.
Sorry for not being more clear. My point is: given that we no longer use
m_currentPosition, and makeSuccessCallbacks() now calls lastPosition() to get
the position directly from the service, positionChanged() could do this too -
i.e. call lastPosition() rather than needing the position to be passed in as a
parameter. So we would remove the Geoposition parameter from positionChanged().

This would allow us to remove the GeolocationPosition parameter from
setPosition(). This would bring the client-based implementation (which uses
setPosition()) into line with the existing implementation (which uses
geolocationServicePositionChanged(), which does not take a position parameter).

Does that make sense?

> Since this would be just a further clarification, I hope you don't mind if I do
> as a follow up?
Sure, no problem

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list