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

Re: skeleton Geolocation API

From: Chris Prince <cprince@google.com>
Date: Wed, 23 Jul 2008 21:50:08 -0700
Message-ID: <cd580da00807232150t323140f0ibacc7a4e189b9983@mail.gmail.com>
To: "Doug Turner" <doug.turner@gmail.com>
Cc: "Shyam Habarakada" <shyamh@microsoft.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>, "Alec Berntson" <alecb@windows.microsoft.com>, "Andrei Popescu" <andreip@google.com>

> 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.

My understanding from the discussion in June was that the first
callback would always be invoked, but with a null position in case of
an error.  And so the errorCallback was only interesting if you wanted
to differentiate between errors.  (Though most web apps seem to opt
for a generic error message in case of errors.)


On Wed, Jul 23, 2008 at 9:20 PM, Doug Turner <doug.turner@gmail.com> wrote:
>
> 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:50:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT