W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Andrei Popescu <andreip@google.com>
Date: Mon, 23 Jun 2008 20:19:31 +0100
Message-ID: <708552fb0806231219p372fa605s7d51bb19840ebe3c@mail.gmail.com>
To: "Doug Turner" <doug.turner@gmail.com>
Cc: "public-geolocation@w3c.org" <public-geolocation@w3c.org>

Hi Doug,

Many thanks for the feedback!

On Sat, Jun 21, 2008 at 1:08 AM, Doug Turner <doug.turner@gmail.com> wrote:
> Hi Andrei,
> Couple of clarifications/questions:
> 1)  Suppose there is the ability for the user to set the geolocation via a
> preference.  For instance, I have a PC in my home office -- it is never
> going to move.  If a webapp calls:
> navigator.geolocation.watchPosition(scrollMap);
> Is the behavior to only call |scrollMap|  "when the position changes", and
> in my example -- it would never be called, right?

It would be called exactly once with the current position. If the
position doesn't change, the callback will not be invoked again.

> 2)  Are there other DOM API that use the object attributes similar to what
> we are doing in watchPosition:
> {successCallback: scrollMap, errorCallback: handleError}

Not that I know of.

> 3) Why are there seperate calls for getCurrentPosition and watchPosition to
> simply pass an options parameter.  Can't we just make that optional and have
> a single call?

We could...it's a matter of taste, I guess. We just thought it's more
elegant to use this way. The option you suggest is to pass the
parameters as follows:

watchPosition(someSuccessCallback, {errorCallback: someErrorCallback});

Not sure this is much better... On the other hand, what is now in the
spec has its supporters, too:


> 4) I am sort of confused on the names geolocation verses position.  My
> thinking was that off of the navigator object would be a "geolocator", and
> that would hand off geolocation objects.  Geolocation implies a position,
> no?

Again, this is a matter of taste. Most people I've talked to didn't
find the current name confusing at all. I'm willing to be convinced
otherwise so let's see if we get more feedback on this topic.

> 5) As discussed before, i think reverse geolocating stuff shouldn't be
> speced here.

Ok. The reason why I thought it could be in the spec is because I
thought that reverse geocoding will be a pretty common usecase. It
would therefore be nice if this API gave developers access to reverse
geocoding even if not all implementations supported it. Given the
rather strong negative feedback, I'll take it out for the time being.

> 6) enableHiqhAccuracy == implementation specific details.  Not sure it is
> that important.  What would a web author set here?  Why would they set it to
> false; and what would they expect?

There is one scenario that we had in mind here: imagine an application
that sets up a long-running position watch and that the application
can live without having very accurate position information (e.g shows
POI in the user's area or something similar). Imagine also that the
application is meant to be used on mobile devices, which are generally
powered by small batteries. If the UA fires up the onboard GPS device
for this, it'll empty the battery quite a lot quicker than it needs
to, resulting in annoyed users who will soon stop using the
application. One solution would be for the application to somehow hint
to the implementation that it doesn't need extremely accurate
information. The implementation would then choose to use a low-power
provider (e.g. network-based), resulting in longer battery life and
happier users.

> 7) I think many of us believe that it should be on the navigator object.
>  and hence,  ClientInformationGeolocation is just what is appended to
> navigator, right?

Yes. Ok, we'll keep it on the navigator object for now.

Received on Monday, 23 June 2008 19:20:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:50 UTC