Re: The getVoices method should be asynchronous.

I agree and propose that the callback MUST be supplied.

All of the options 1,2,3 are bad and would require extra handling, so they
are only complicating the requirements for both the user agent and the
JavaScript developer. The callback provides a practical solution that's
easy to implement in the user agent and JavaScript, and supports local and
remote speech synthesizers.



On Tue, May 28, 2013 at 2:20 AM, Hans Wennborg <hwennborg@google.com> wrote:

> On Tue, May 28, 2013 at 9:14 AM, Dominic Mazzoni <dmazzoni@google.com>
> wrote:
> > Eitan said he agrees - any other opinions?
>
> Sounds good to me.
>
>  - Hans
>
> > On Tue, May 21, 2013 at 9:01 AM, Dominic Mazzoni <dmazzoni@google.com>
> > wrote:
> >>
> >> I filed the following bug, does anyone have any thoughts?
> >>
> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22003
> >>
> >> The getVoices method should be asynchronous.
> >>
> >> As it is right now, user agents have three choices, all bad:
> >>
> >> 1. They can pre-load speech synthesis, which slows down application
> >> startup even though most web pages don't speak.
> >> 2. They can block until the list of voices is available, which can make
> >> the browser appear sluggish and potentially freeze script execution on
> that
> >> page for tens of milliseconds.
> >> 3. They can return an empty list and update it as soon as the complete
> >> list of voices is available.
> >>
> >> I propose that getVoices take a callback as an argument, so you'd use it
> >> like this:
> >>
> >> window.speechSynthesis.getVoices(function(voices) {
> >>   for (var i = 0; i < voices.length; i++)
> >>     ...
> >> });
> >>
> >> If the callback is unspecified, we could allow it to be used
> synchronously
> >> - and we should recommend browsers adopt either #2 or #3.
> Alternatively, we
> >> could just remove support for the synchronous form, and require the
> >> callback.
> >>
> >
>
>