Re: skeleton Geolocation API

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 Friday, 27 June 2008 18:59:52 UTC