- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 30 Jul 2008 16:21:02 +0100
- To: "Chris Butler" <cbutler@dash.net>
- Cc: "Shyam Habarakada" <shyamh@microsoft.com>, "Alec Berntson" <alecb@windows.microsoft.com>, "Doug Turner" <doug.turner@gmail.com>, "Chris Prince" <cprince@google.com>, "Aaron Boodman" <aa@google.com>, public-geolocation@w3c.org
Hi Chris, On Tue, Jul 29, 2008 at 5:13 PM, Chris Butler <cbutler@dash.net> wrote: > Hi everyone. > > Debugging is an interesting issue, but in the case of timeouts they > don't provide much good information. I agree. > To find where the timeout took > place it requires special tools or specific knowledge of all steps of > the process. Right again. I also think that the users of the Geolocation API won't really care what specific steps are involved in getting a location. > it doesn't really matter whether it is a computer, transmission or service issue since either way > the user can't do some function. Exactly. > Also, we should assume that when we say timeout we mean from the initial > creation of the async request and the response being processed and > available to the callback, right? I assume so. One use I see for timeouts is as a developer-supplied value, possibly on the PositionOptions interface. Such an option would tell the Geolocation API implementation to invoke the error callback if a valid position cannot be acquired in a given time. On the other hand, something similar can be achieved using window.setTimeout(), so I am not entirely sure we actually need this functionality in our spec. Andrei
Received on Wednesday, 30 July 2008 15:21:45 UTC