- From: Shyam Habarakada <shyamh@microsoft.com>
- Date: Wed, 23 Jul 2008 23:42:31 -0700
- To: Aaron Boodman <aa@google.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>
Comment inline -----Original Message----- From: Aaron Boodman [mailto:aa@google.com] Sent: Wednesday, July 23, 2008 10:21 PM > > 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. [shyam] Yes, I mean call clearWatch(watchId). > > 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. [shyam] Yes, my last two emails weren't very clear on whether the errorCallback should be optional or mandatory. And I don't think I still have a strong opinion on this. The current spec implies that it is optional and the feedback provided earlier was that it doesn't make much sense to have that as optional. On further review, there are several questions we should try to answer before deciding on if errorCallback is mandatory or not: 1. Are there use-case where errors SHOULD be ignored? 2. If we say errorCallback MUST be provided and a caller does not comply, what is the desired runtime behavior? Throw an exception? 3. Are there error scenarios where we MUST signal the caller to invoke clearWatch(watchID)?
Received on Thursday, 24 July 2008 06:43:14 UTC