Re: skeleton Geolocation API - Error codes

Hi Shyam,

On Mon, Aug 18, 2008 at 6:25 PM, Shyam Habarakada <shyamh@microsoft.com> wrote:
>
> How would timeout apply in the watch scenario?

My idea was:

<snip>
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.
</snip>

> 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

True, that's one way to look at it. On the other hand, I was thinking
that timeouts could also make sense for watch scenarios, as described
above. It's also more consistent to allow timeouts in both APIs. What
do you think?

> 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.

I tried to present a detailed proposal in my previous email (see also
below) :) Maybe we could use that as a base for discussion?

All the best,
Andrei

> -----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
>>
>>
>>

Received on Monday, 18 August 2008 18:15:13 UTC