- From: Thomson, Martin <Martin.Thomson@andrew.com>
- Date: Wed, 19 Nov 2008 14:50:12 -0600
- To: "Doug Turner" <doug.turner@gmail.com>
- Cc: "Greg Bolsinga" <bolsinga@apple.com>, "Andrei Popescu" <andreip@google.com>, "Aaron Boodman" <aa@google.com>, "public-geolocation" <public-geolocation@w3.org>, "Richard Barnes" <rbarnes@bbn.com>
That option would be acceptable. In other forums, I've proposed a separate indicator (a Boolean flag) but that is because the error codes were already defined at a different conceptual layer in the protocol. Rolling that into the PositionError would work. > -----Original Message----- > From: Doug Turner [mailto:doug.turner@gmail.com] > Sent: Wednesday, 19 November 2008 1:18 PM > To: Thomson, Martin > Cc: Greg Bolsinga; Andrei Popescu; Aaron Boodman; public-geolocation; > Richard Barnes > Subject: Re: Drop lastPosition from Geolocation? > > > > > Note that with my proposal, you can still achieve the availability > > goal. Instead of including a position in the error callback, you > > include an indication that cached data is available, but it was not > > “fresh” enough. > > Are you suggesting that instead of returning position unavailable, we > add a new error code that expresses the fact that we might have a > position available but it is outside of the "freshness" that you > wanted? ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]
Received on Wednesday, 19 November 2008 20:55:04 UTC