- From: Andrei Popescu <andreip@google.com>
- Date: Mon, 24 Nov 2008 16:26:01 +0000
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: Doug Turner <doug.turner@gmail.com>, Greg Bolsinga <bolsinga@apple.com>, Aaron Boodman <aa@google.com>, public-geolocation <public-geolocation@w3.org>, Richard Barnes <rbarnes@bbn.com>
Hello, I'd like to thank everyone for your comments. I have removed Geolocation::lastPosition from the spec and I have added a new attribute on PositionOptions, as discussed: http://dev.w3.org/geo/api/Overview.html#max-age I have called it 'maximumAge' because I thought it reflects its semantics better than 'modifiedSince'. I have also provided extensive examples that show typical usage of this attribute. Please have a look. Andrei On Wed, Nov 19, 2008 at 8:50 PM, Thomson, Martin <Martin.Thomson@andrew.com> wrote: > 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 Monday, 24 November 2008 16:26:43 UTC