RE: skeleton Geolocation API

In the 'get' scenario, only one of the two (success or error) callbacks would get invoked. IOW, it would be incorrect to say that the first callback (successCallback) would always be invoked.

In the watch scenario, it doesn't look like we've gone into details on the behaviors yet. IMO, either of the two callbacks may get invoked while watching for position changes, and the caller must have the option of removing itself from the watch list at any point.

I agree on the feedback below that errorCallback should not be optional. This would make the signature look like,

    getPosition(successCallback, errorCallback [, positionOptions]).


-----Original Message-----
From: Chris Prince [mailto:cprince@google.com]
Sent: Wednesday, July 23, 2008 9:50 PM
To: Doug Turner
Cc: Shyam Habarakada; public-geolocation@w3c.org; Alec Berntson; Andrei Popescu
Subject: Re: skeleton Geolocation API

> that use case work?  My thinking is that without an error callback, the
> successCallback will never be called.  And that seems like we are
> positioning this error callback as "optional" but it really isn't.  And that
> means, I think we should be passing the status code into the callback.

My understanding from the discussion in June was that the first
callback would always be invoked, but with a null position in case of
an error.  And so the errorCallback was only interesting if you wanted
to differentiate between errors.  (Though most web apps seem to opt
for a generic error message in case of errors.)


On Wed, Jul 23, 2008 at 9:20 PM, Doug Turner <doug.turner@gmail.com> wrote:
>
> Another option would be to pass an object as the first parameter which
> contains all callbacks.
>
> var callbacks = {
>  "onSuccess" : function (position) {},
>  "onFailure" : function(status) {},
> };
>
> getPosition(callbacks [, options] )l
>
> I am not sure I like this any better than (C), but it does it us around the
> problem of having to pass null in the middle of a call when the error
> callback is not provided.
>
>  Is there ever a time when the developer should not be looking for error?
>  For example, there are so many things that can go wrong setting up the
> geolocation device (gps, wifi->location, etc).  The common error might be
> that the geolocation device doesn't find a location for the user.  How does
> that use case work?  My thinking is that without an error callback, the
> successCallback will never be called.  And that seems like we are
> positioning this error callback as "optional" but it really isn't.  And that
> means, I think we should be passing the status code into the callback.
>
> Doug Turner
>
>
> On Jul 23, 2008, at 5:56 PM, Shyam Habarakada wrote:
>
>>
>> // Re-posting to public-geolocation@w3c.org
>>
>> We had a forked email thread on how best to provide the callbacks to the
>> get and watch APIs. The main problem we were trying to improve on was the
>> current approach of passing the callbacks as members of PositionOptions. The
>> 3 alternates we identified are,
>>
>> A. Have only a single callback with Position.ErrorCode denoting if there
>> was an error
>> B. Have only a single callback with Position and PositionStatus being two
>> independent parameters passed back via the callback
>> C. Have separate callbacks for success and error scenarios.
>>
>> Of these 3, we prefer C. With this approach, the signature of getPosition
>> would look like
>>
>>   getPosition(successCallbac [, errorCallback [, positionOptions]]).
>>
>> Here, if the user is specifying positionOptions, but does not want to
>> provide an errorCallback, they would have write code like
>>
>>   getPosition(successCallback, null, positionOptions).
>>
>> The same would apply for watchPositions.
>>
>> Looking for broader comments on the above. Thanks
>>
>>
>> shyam habarakada
>> Microsoft Corporation
>>
>>
>>
>> -----Original Message-----
>> From: Shyam Habarakada
>> Sent: Thursday, July 03, 2008 2:28 PM
>> To: 'Andrei Popescu'
>> Cc: Alec Berntson
>> Subject: RE: skeleton Geolocation API
>>
>> Apologies for not getting back sooner - on the callback, our current
>> options are
>>
>> A. Have only a single callback with Position.ErrorCode denoting if there
>> was an error
>> B. Have only a single callback with Position and PositionStatus being two
>> independent parameters passed to the callback
>> C. Have separate callbacks for success and error scenarios.
>>
>> In C above, the signature of getPosition would look like
>> getPosition(successCallback [, errorCallback [, positionOptions]]). Here, if
>> the user is specifying positionOptions, but does not want to provide an
>> errorCallback, they would have write javascript like
>> getPosition(successCallback, null, positionOptions). The same would apply
>> for watchPositions.
>>
>> IMO, C allows for the cleanest usage and seems the most intuitive to me. B
>> is acceptable also but A is not.
>>
>> Thanks
>> shyam
>>
>> -----Original Message-----
>> From: Andrei Popescu [mailto:andreip@google.com]
>> Sent: Thursday, July 03, 2008 1:24 PM
>> To: Shyam Habarakada
>> Cc: Alec Berntson
>> Subject: Re: skeleton Geolocation API
>>
>> - public-geolocation
>>
>> Hi guys,
>>
>> I just wanted to ping you and ask if you have come to a conclusion
>> about the PositionCallback issue. I'd also like to kindly ask you to
>> look at the last draft I just published and let me know if you think
>> it needs other changes.
>>
>> Many thanks,
>> Andrei
>>
>> On Fri, Jun 27, 2008 at 7:59 PM, Andrei Popescu <andreip@google.com>
>> wrote:
>>>
>>> Hi Shyam,
>>>
>>> On Thu, Jun 26, 2008 at 10:11 PM, Shyam Habarakada <shyamh@microsoft.com>
>>> wrote:
>>>>
>>>> Andrei,
>>>> I just noticed that you had moved the errorCallback (as well as another
>>>> reference to the successCallback) into PositionOptions. This seems like a
>>>> strange API design to me, but I can see why you may have gone this route (I
>>>> did not see a detail discussion on the WG that lead to this approach). Given
>>>> the way argument passing and function overloading works in javascript, it is
>>>> tricky to do something like getPosition(successCallback [, errorCallback] [,
>>>> positionOptions]) as I originally suggested to the WG.
>>>>
>>>> A cleaner approach might be to revert to a single callback approach and
>>>> modify the signature of the callback so that Position and Error/Status data
>>>> is decoupled.
>>>>
>>>> Say,
>>>>
>>>> interface PositionCallback {
>>>>  void handleEvent(in PositionStatus status, in Position position);
>>>> };
>>>>
>>>> Where,
>>>>
>>>> interface PositionStatus {
>>>>  readonly int code;
>>>>  readonly DOMString message;
>>>> };
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>
>>> I think this is certainly a good idea. The implication, however, is
>>> that 100% of the code using this API would look as follows:
>>>
>>> if (!status.code) {
>>> callSuccessHanlder();
>>> } else {
>>> callErrorHandler(status.code);
>>> }
>>>
>>> How would you feel about leaving the errorCallback as a property of
>>> the PositionOptions interface and having the successCallback always be
>>> the first parameter?
>>>
>>> Many thanks,
>>> Andrei
>>>
>>
>>
>
>
>

Received on Thursday, 24 July 2008 05:08:19 UTC