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

RE: skeleton Geolocation API

From: Alec Berntson <alecb@windows.microsoft.com>
Date: Thu, 24 Jul 2008 09:47:39 -0700
To: Aaron Boodman <aa@google.com>, Shyam Habarakada <shyamh@microsoft.com>
CC: Chris Prince <cprince@google.com>, Doug Turner <doug.turner@gmail.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>, Andrei Popescu <andreip@google.com>
Message-ID: <D8939A2F7A8C124ABE6075E08C52CDCA031C369DC9@TK5-EXMBX-W603v.wingroup.windeploy.ntdev.microsoft.com>

That was the use case I was thinking about for 1. I don't know if this is a strong enough reason to make the callback optional
I agree with 2.
As for 3, I don't think there is a permanent, 'no more location ever' error. I agree that the implementation will just not send callbacks if the provider(s) (or privacy controls) are not currently giving location data.

-----Original Message-----
From: Aaron Boodman [mailto:aa@google.com]
Sent: Wednesday, July 23, 2008 11:52 PM
To: Shyam Habarakada
Cc: Chris Prince; Doug Turner; public-geolocation@w3c.org; Alec Berntson; Andrei Popescu
Subject: Re: skeleton Geolocation API

On 7/23/08, Shyam Habarakada <shyamh@microsoft.com> wrote:
>  1. Are there use-case where errors SHOULD be ignored?

Should? No, but I can imagine use cases where a developer simply
doesn't care about errors and wants to ignore them. For example, say I
call watchPosition() to trace a user's position on a map. I might
implement it like this:

1. Show status UI telling the user we are looking for a fix, with a
button to cancel
2. Call watchPosition()
3. When we get the first fix, clear the status UI and update the position
4. For each new fix, update the position again

For this hypothetical usage, I don't really care about getting errors.

>  2. If we say errorCallback MUST be provided and a caller does not comply, what is the desired runtime behavior? Throw an exception?

Usually, if a parameter is required, then the behavior is to throw
when the function is called. That makes sense here too.

>  3. Are there error scenarios where we MUST signal the caller to invoke clearWatch(watchID)?

No. If the error is permanent, the implementation will just never call
either callback again.

- a
Received on Thursday, 24 July 2008 16:48:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT