W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

Re: DAP-ISSUE-149: handling of long vibration list - truncate or no vibration at all [Vibration API]

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Thu, 3 Oct 2013 08:48:21 +0000
To: Device APIs Working Group <public-device-apis@w3.org>
Message-ID: <CFAC989F-E7D5-4908-BE25-FD03AA32DD88@intel.com>
On Sep 4, 2013, at 6:52 PM, Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

> DAP-ISSUE-149: handling of long vibration list - truncate or no vibration at all [Vibration API]
> 
> http://www.w3.org/2009/dap/track/issues/149
> 
> Raised by: Frederick Hirsch
> On product: Vibration API
> 
> raised by Daniel Glazman
> 
> http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0050.html
> 
> comment on 20130723 CR, section 4 #3 and #5
> 
> I have a comment about the Vibration API CR:
> 
> If I understand them correctly, section 4 items 3 and 5 say that the
> requested vibration are entirely dropped in case of overflow beyond
> implementation-dependent limits. So let's say an app calls
> 
>   navigator.vibrate([50, 100, 150, 100, 150]);
> 
> but the device is unable to handle a list of more than 3 values,
> the device will not vibrate at all. Why that choice and not a
> truncated list? Same thing for the duration of a vibration or silence,
> why not a fallback to the implementation limit?
> It seems to me that getting absolutely no result based on an
> unpredictable device dependency is not something that developers will
> like...

This proposal sounds reasonable to me. Below is my suggestion how the algorithm could be changed to address Daniel's concerns.

The relevant steps in the algorithm are currently the following:

[[

3. If the length of /pattern/ exceeds an implementation-dependent limit, then return false and terminate these steps.

[...]

5. If any entry of /pattern/ exceeds an implementation-dependent limit, then return false and terminate these steps.

]]

And here's my proposal how to address this:

[[

[NEW] Let /max length/ be the /pattern/'s implementation-dependent maximum length.

3. If the length of /pattern/ is greater than /max length/, truncate /pattern/, leaving only the first /max length/ entries.

[...]

[NEW] Let /max duration/ be an implementation-dependent maximum duration for a single vibration entry in a /pattern/.

5. For each entry in /pattern/ whose value is greater than /max duration/, set the entry's value to /max duration/.

]]

All - please review this proposal, and let the group know if you have any concerns with this change.

Thanks,

-Anssi
Received on Thursday, 3 October 2013 08:48:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC