W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Andrei Popescu <andreip@google.com>
Date: Fri, 27 Jun 2008 19:59:09 +0100
Message-ID: <708552fb0806271159x435555f1u44ea1c5b0a3717a5@mail.gmail.com>
To: "Shyam Habarakada" <shyamh@microsoft.com>
Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>, "Alec Berntson" <alecb@windows.microsoft.com>

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) {
} else {

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC