- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 16 Feb 2011 00:20:31 +0000
- To: Steve Block <steveblock@google.com>
- Cc: Dean Jackson <dino@apple.com>, public-geolocation@w3.org
On Tue, Feb 15, 2011 at 6:37 PM, Steve Block <steveblock@google.com> wrote: >> The reasoning is that a developer shouldn't really be concerned with calibration. All they really need to know >> is the accuracy of the data they are seeing. > I disagree. Exposing information about whether the device needs > calibrating is important as it allows the web app to ask the user to > address this where appropriate. > So then most apps will have to write code for handling the case when the sensor isn't calibrated. I was initially thinking that we could maybe let the UA notice this and handle it so that the Web app developer wouldn't be concerned about it. But, more often than not, I've seen Web apps developers preferring to have full control over the UI, rather than letting the browser pop up dialogs/infobars at random times. So I tend to agree with you that the right tradeoff is to let the Web app control when and how to ask the user to calibrate the sensor. >> I believe the feedback has two core parts: to avoid the term calibration, and to give some variance. > If you'd like to add information about the accuracy of the data, this > seems to be largely orthogonal to concerns about calibration (a > correctly calibrated device may still be inaccurate). Trying to > combine accuracy and calibration in a single enum seems awkward, > particularly if we're to include an 'unknown' value for either or both > concepts. > The question is then whether we should add a separate 'accuracy' property. But what exactly would the usecases for it be? Thanks, Andrei > Steve > > -- > Google UK Limited > Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ > Registered in England Number: 3977902 >
Received on Wednesday, 16 February 2011 00:21:02 UTC