- From: Andrei Popescu <andreip@google.com>
- Date: Mon, 7 Dec 2009 15:34:11 +0000
- To: Steve Block <steveblock@google.com>
- Cc: Max Froumentin <maxfro@opera.com>, public-geolocation <public-geolocation@w3.org>
On Thu, Dec 3, 2009 at 3:21 PM, Steve Block <steveblock@google.com> wrote: >>>> Test 00133: call watchPosition() with wrong type for third argument. Exception expected. >>> I don't think that any type passed for the positionOptions argument >>> should cause an exception. The spec states that 'PositionOptions >>> objects are regular ECMAScript objects ...' and all of its properties >>> are optional. In JS, any type can be converted to a (perhaps empty) >>> object. The implementation should simply check for the presence of the >>> relevant properties, but never throw an exception. See the WebKit test >>> linked above. >> >> Do you think that the specification should be more explicit about the above? > That's probably a good idea. > >>>> Test 00031: pass if getCurrentPosition returns withing 100ms >>> >>> I'm not sure it's useful to test that the function returns within a >>> particular time limit, as the spec doesn't specify such a limit. I >>> think the important thing to check is that the callbacks are always >>> invoked asynchronously, rather than from within the function call. >> >> The statement that this test is checking is "must immediately return", >> though. Clearly the test isn't great but I can't think of another way to >> check. > Sure, but I think the intent of the spec is not to limit the time > taken by the method to return, but to require that the location > acquisition process and the callbacks should be asynchronous. Andrei, > can you clarify? > Yes, the intention is to require the acquisition process to happen asynchronously. The same wording exists in other specs, for example here: http://dev.w3.org/html5/webdatabase/#dom-database-transaction Thanks, Andrei
Received on Monday, 7 December 2009 15:34:52 UTC