Re: skeleton Geolocation API - Error codes

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 Friday, 15 August 2008 14:47:42 UTC