Re: skeleton Geolocation API

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 04:20:46 UTC