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

Re: PositionError - DOMString message

From: Doug Turner <doug.turner@gmail.com>
Date: Tue, 14 Oct 2008 08:01:28 -0700
Cc: public-geolocation <public-geolocation@w3.org>
Message-Id: <1B59D72E-1509-4699-8665-63542D9C57E6@gmail.com>
To: "Andrei Popescu" <andreip@google.com>


On Oct 14, 2008, at 7:52 AM, Andrei Popescu wrote:

> On Tue, Oct 14, 2008 at 3:49 PM, Doug Turner <doug.turner@gmail.com>  
> wrote:
>>
>> On Oct 14, 2008, at 4:50 AM, Andrei Popescu wrote:
>>
>>> On Tue, Oct 14, 2008 at 12:48 AM, Doug Turner  
>>> <doug.turner@gmail.com>
>>> wrote:
>>>>
>>>> If I recall correctly, the message attribute on the position  
>>>> error was
>>>> suppose to be for debugging purposes.  However, it was brought up  
>>>> that
>>>> this
>>>> message may be displayed to the user.  Should this string be  
>>>> localized?
>>>> Should we change the draft spec to suggest that this string is  
>>>> localized
>>>> and can be displayed to the user?
>>>>
>>>
>>> Hmm, not sure. I think most implementations will end up using
>>> different strings. If those strings are shown to the user, then the
>>> error messages that the user sees will be quite technical and will
>>> also look different depending on the UA that she is happening to be
>>> using at the time, which may be somewhat confusing. I'm thinking  
>>> that
>>> the applications that use the Geo API are in a better position to
>>> handle the UI for the error situations, so we should not encourage
>>> them to just print out the API error messages.
>>>
>>> Andrei
>>
>>
>> Then I guess I am not sure of the value of such an error message in  
>> our API.
>>
>
> I see some value for application developers who want to debug their  
> apps.
>
> Andrei


if the error code is 4, the text message would probably be "Timeout  
Error." or similar.  How is this any better than just the numeric  
value?  so, this is something like extended debug information?
Received on Tuesday, 14 October 2008 15:02:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:51 UTC