RE: skeleton Geolocation API

// 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 01:26:23 UTC