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

Re: skeleton Geolocation API

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

On Wed, Jul 23, 2008 at 10:07 PM, Shyam Habarakada <shyamh@microsoft.com> wrote:
> In the 'get' scenario, only one of the two (success or error) callbacks would get invoked. IOW, it would be incorrect to say that the first callback (successCallback) would always be invoked.

True. I think Chris was remembering an earlier version of the API.

> In the watch scenario, it doesn't look like we've gone into details on the behaviors yet. IMO, either of the two callbacks may get invoked while watching for position changes,

Yes. In fact, you could get an error callback, and then a success
callback later (the error might be transient).

> and the caller must have the option of removing itself from the watch list at any point.

By "remove itself from the watch", you mean call clearWatch()? If so,
then yes. If you mean replace the error callback independent of the
success callback, then no. I don't think the latter is necessary.

> I agree on the feedback below that errorCallback should not be optional. This would make the signature look like,
>
>    getPosition(successCallback, errorCallback [, positionOptions]).

We need to be precise in what we mean by 'optional'. Earlier, you said
that you felt that the author should be able to send null if he didn't
want errors:

getPosition(successCallback, null, positionOptions);

If this is true (and I think it should be), the argument really is
optional and you may as well allow the author to not pass it.
Requiring the null is just busy work. That is, this should also be
legal:

getPosition(successCallback)

As for where to put the error callback, I can see both sides of this
particular bike shed. On one hand, I agree with Chris's point that if
the thing is optional, it might as well go with the other optional
things, in positionOptions. OTOH, I can see how one might think it is
slightly more aesthetically pleasing to have the error callback
separate, and have the two callbacks side by side.

I can live with this either way.

- a
Received on Thursday, 24 July 2008 05:22:12 GMT

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