Re: skeleton Geolocation API

>  getPosition(successCallbac [, errorCallback [, positionOptions]]).

So errorCallback and positionOptions would both be optional, if I'm
reading this correctly?

It seems odd that errorCallback would be a "special" optional
parameter.  If callers want to pass a positionOptions attribute but
not errorCallback, why force them to provide a 'null' errorCallback
parameter?  I'm unclear on how that's helpful.


On Wed, Jul 23, 2008 at 5:56 PM, Shyam Habarakada <shyamh@microsoft.com> 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 03:17:11 UTC