Re: skeleton Geolocation API - Error codes

[apologies for the late comments]

How would timeout apply in the watch scenario?

Intuitively, I would guess that there would never be a timeout in this scenario and the successCallback would simply not get called. IOW, timeout only seems to make sense in the get scenario and we should think more about what this means from an API design perspective and be more specific about how this applies to the two major APIs.

shyam habarakada
Microsoft Corporation

p.s. We should fork this discussion on timeouts ...


-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com]
Sent: Monday, August 18, 2008 10:07 AM
To: Doug Turner
Cc: Chris Butler; public-geolocation@w3c.org; Shyam Habarakada; Alec Berntson; Chris Prince; Aaron Boodman; Aza
Subject: Re: skeleton Geolocation API - Error codes

Hi,

Any thought on this? If not, this is what I'll put in the spec.

Andrei

On Fri, Aug 15, 2008 at 3:46 PM, Andrei Popescu <andreip@google.com> wrote:
> Hi,
>
> Ok since nobody spoke against timeouts, I will add this concept to the
> spec. Here's my proposal:
>
> //----------------------
>
> interface PositionOptions {
>    (...)
>    long timeout;
> };
>
> The timeout attribute denotes the maximum length of time (expressed in
> milliseconds) that is allowed to pass from the the call to
> getCurrentPosition() or watchPosition() until the corresponding
> successCallback is invoked. If the implementation is unable to
> successfully acquire a new Position before the given timeout elapses,
> and no other errors have occurred in this interval, then the
> corresponding errorCallback must be invoked with a PositionError
> object whose code attribute is set to 4.
>
> In case of a getCurrentPosition() call, the errorCallback would be
> invoked exactly once.
>
> In case of a watchPosition(), the errorCallback could be invoked
> repeatedly: the first timeout is relative to the moment
> watchPosition() was called, while subsequent timeouts are relative to
> the moment when the implementation determines that the position of the
> hosting device has changed and a new Position object must be acquired.
>
> (...)
>
> PositionError interface
>
> interface PositionError {
>    readonly int code;
>    readonly DOMString message;
>  };
>
>
> The code attribute must return the appropriate code from the following list:
>
> (...)
>
> 4 - Timeout: The specified maximum length of time has elapsed before
> the implementation could successfully acquire a new Position object.
>
> //-------------------
>
> Please let me know what you think.
>
> Andrei
>
>
>
> On Mon, Aug 11, 2008 at 10:09 PM, Doug Turner <doug.turner@gmail.com> wrote:
>>
>>
>> On Aug 11, 2008, at 1:51 PM, Andrei Popescu wrote:
>>
>>> Hi Chris,
>>>
>>> On Mon, Aug 11, 2008 at 2:44 PM, Chris Butler <cbutler@dash.net> wrote:
>>>>
>>>> Hi Andrei.
>>>>
>>>> I think there was consensus that we should have timeouts as part of the
>>>> API as an error scenario with the ability to set the timeout period.
>>>>
>>>> Was there something I missed that was a strong argument against?
>>>>
>>>
>>> I wasn't sure there was consensus, since there was the argument that
>>> you could achieve the same functionality using window.setTimeout().
>>> However, I do agree with you that allowing the developer to specify a
>>> timeout via PositionOptions is a nice-to-have feature. Does anyone
>>> strongly disagree with adding this to the spec?
>>>
>>> Andrei
>>
>>
>> You can not support this functionality with window.setTimeout() unless getCurrentPosition returns something that is cancelable.  I think this is a good addition.  We can support this via  a new error code on PositionError.
>>
>> Regards,
>> Doug
>>
>>
>>
>>
>>
>>
>>
>

Received on Monday, 18 August 2008 17:37:53 UTC