Sorry for coming to it bit late...
About the added Step 9 "An implementation may abort the algorithm at this point".
I don't think abort is the only feasible option. There is always a functionality at native layer to disable the Vibrator i.e user may switch it OFF. So in this case won't it be suitable to first know whether the Vibrator is OFF? If it is, then user may be given an option to switch it on for specific time or for particular page/application?
To achieve this we just need a method like VibState() returning constants like "VibON" or "VibOFF". Depending on which it can be ascertained whether to continue to step 10 or abort.
Note: Vibrator may be switched OFF by default, or it may be accidently switched OFF. So, it is worth for developers to try to get it ON for better user experience.
Regards
Deepanshu Gautam
Service Standards, Huawei Software
T: +86 25 5260008 M: +86 135 85147627
-----Original Message-----
From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com]
Sent: Monday, November 14, 2011 9:38 PM
To: ext Justin Lebar
Cc: Jonas Sicking; public-device-apis@w3.org; public-device-status@w3.org
Subject: Re: [vibration] Preliminary thoughts on the vibrator spec
On 11.11.2011, at 23.16, ext Justin Lebar wrote:
>> An implementation should be allowed to disable vibration in any way if it wants to for security or privacy reasons.
>
> Jonas> I think "is" would be more correct than "should be".
>
> This is still too restrictive. An implementation may also disable
> vibration just because the user asked. Also, I don't know what it
> means to disable vibration "in any way."
>
> How about we add a step to the algorithm, between steps 8 and 9:
>
> "9) An implementation may abort the algorithm at this point.
>
> "Non-normative note: For example, an implementation might abort the
> algorithm because the user has set a preference indicating that pages
> at a given origin should never be able to vibrate the page, or an
> implementation might cap the total amount of time a page may cause the
> device to vibrate and reject requests in excess of this limit."
This looks good to me. I added the step and the non-normative note you proposed to the spec.
Thanks!
-Anssi