[vibration] Re: Preliminary thoughts on the vibrator spec

Hi Justin,

On 4.11.2011, at 0.35, ext Justin Lebar wrote:

> At the meeting today I said I'd send out some thoughts on the vibrator
> spec after reading it.  Here they are.
> 
> Section 3.1 says no exceptions for vibrate, but it may throw NotSupportedError.

Defined NotSupportedError exception in 3.1.	

> I don't think you need the |already started| flag.  It guards
> cancellations of the algorithm, but you can just unconditionally
> "cancel the pre-existing instance of the processing vibration
> algorithm, if any".

I agree we can simplify the algorithm by removing the flag. The flag is now gone.

> Need to indicate that if the device doesn't have a vibrator, or the
> user has disabled the vibrator (globally, or for this page), we
> silently ignore the vibration request.

Added the following prose:

[[

If the device does not provide a vibration mechanism, or it is disabled, the user agent must silently ignore any invocations of the vibrate() method.

]]

> Algorithm step 2: If a page is hidden and calls vibrate(...), why do
> we cancel other instances of the algorithm?

I removed this, and defined additional steps for visibilitychange event to handle background tab pause and resume.

> Algorithm step 5: "If pattern is 0 or an empty list, cancel the
> pre-existing attempt, if any,"  What does it mean to cancel the
> pre-existing attempt?  Is that the same as canceling the pre-existing
> instance of the processing vibration patterns algorithm?  If this is
> annoying to type, let's declare a more concise synonym.

Lets call it "the pre-existing instance of the processing vibration patterns algorithm" to be explicit. Or if you have a better name in mind, just let me know. Now the spec refers to this term consistently.

> Algorithm step 5: "If pattern is 0, an empty list," **null, or undefined**

There was earlier discussion that including null and undefined may not make sense so they were dropped:

  http://lists.w3.org/Archives/Public/public-device-status/2011Oct/0048.html

I added null and undefined back for now, this should be a minor issue anyway.

> Algorithm step 7: Throw if any entry is not a non-negative number.

I made the vibrate() arguments of type 'unsigned long' and 'unsigned long[]'. This should relegate throwing exceptions for negative numbers to Web IDL.

> Algorithm steps 8, 10: Can we use "even" instead of "divides by 2
> leaving no remainder"?  If you don't want to rely on the fact that 0
> is even, you can always test for oddness.

Changed to simpler form as per your suggestion.

I checked the algorithm for processing vibration patterns against your manual test case, but it would be great if you could double check it against your implementation and let me know if there are any further issues:

  http://dev.w3.org/2009/dap/vibration/

Thanks for your extremely helpful feedback!

-Anssi

Received on Wednesday, 9 November 2011 12:58:44 UTC