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

Re: Vibration: throwing and pause

From: Justin Lebar <justin.lebar@gmail.com>
Date: Tue, 16 Apr 2013 01:22:35 +0200
Message-ID: <CAFWcpZ6N=HcYdDpNPmgtTh-R7hKXhy7g3WtW26L1Y4hiHzAf8g@mail.gmail.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-device-apis@w3.org" <public-device-apis@w3.org>
> * In step 10 say "run the following substeps asynchronously".

Is this well-defined?

Perhaps the right thing is to "spawn a task," but my network
connection is too poor for me to look that up right now!

On Mon, Apr 15, 2013 at 11:14 PM, Kostiainen, Anssi
<anssi.kostiainen@intel.com> wrote:
>
> On Apr 13, 2013, at 11:24 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> >> The method is definitely not intended to be synchronous in Firefox's
> >> implementation.
> >>
> >> I don't even know what it means to synchronously do an operation like this.
> >> Obviously the vibrate() call doesn't block until the phone starts
> >> moving, or something like that.
>
> I tried to say that from the developer's point of view the method works as "fire and forget". An implementation surely should be asynchronous.
>
> >> Could you elaborate on how making this method sync and spinning the event loop
> >> impacts content authors?  I agree with Anne that making this sync seems Very
> >> Bad.
> >
> > Yeah, it should simply return early and then asynchronously do the
> > vibration bits.
>
>
> A proposal:
>
> * IDL change: vibrate() returns boolean.
> * In steps 3 and 5 return false instead of throwing.
> * In steps 6, 7 and 9 return false instead of aborting.
> * Between current steps 9 and 10 return true.
> * In step 10 say "run the following substeps asynchronously".
>
> Would that work for you? Any bugs?
>
> -Anssi
Received on Monday, 15 April 2013 23:23:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC