Re: [speechXG] parameter setting for the recognition object

It's not really exiting a thread. It's more like the browser has a
single thread with a top-level loop that waits for events and calls
JavaScript code to handle them. The execution model is pretty
different from normal apps, and there isn't really any multithreading
etc.

In my mind, we are developing an API for use in web pages, so it
should be designed to work in a browser. As such, we don't have to
worry about things like multithreading, and can assume that we are
running in an event loop.

Browser implementors: please correct any misconceptions that I have.

/Bjorn

On Thu, Jul 28, 2011 at 12:37 PM, Young, Milan <Milan.Young@nuance.com> wrote:
> From your message below, it sounds like you are assuming that access to
> the API will be contained within callback functions like onClick.
> Changes to the underlying speech objects (and thus all protocol
> communication) would block until the thread exits.  Correct?
>
> Not coming from a browser development background, I still think of
> applications in terms of a monolithic structure that has its own threads
> etc.  I don't know if anyone actually programs in that way, but it makes
> me nervous that our API might not be useable in that paradigm.
>
> Is this a valid concern?
>
>
> -----Original Message-----
> From: Bjorn Bringert [mailto:bringert@google.com]
> Sent: Thursday, July 28, 2011 12:11 PM
> To: Young, Milan
> Cc: Deborah Dahl; HTML Speech XG
> Subject: Re: [speechXG] parameter setting for the recognition object
>
> I believe that the browser event loop would take care of this. The
> browser should defer telling the speech recognizer about the changed
> parameters until it finishes processing the current JavaScript
> invocation. For example, I think that this is how changing DOM
> attributes of visible elements is done without intermediate states
> being rendered.
>
> /Bjorn
>
> On Thu, Jul 28, 2011 at 11:57 AM, Young, Milan <Milan.Young@nuance.com>
> wrote:
>> Bjorn, are you arguing that we don't need to solve this problem, or
> that
>> something about the JavaScript flow control implicitly handles the
>> issue?
>>
>> Thanks
>>
>>
>> -----Original Message-----
>> From: public-xg-htmlspeech-request@w3.org
>> [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Bjorn
> Bringert
>> Sent: Thursday, July 28, 2011 11:23 AM
>> To: Deborah Dahl
>> Cc: HTML Speech XG
>> Subject: Re: [speechXG] parameter setting for the recognition object
>>
>> My suggestion towards the end was to not have any special API support
>> for atomically setting multiple parameters. That is, neither a map nor
>> updateParameters(). This would match how setting parameters on DOM
>> elements works.
>>
>> /Bjorn
>>
>> On Thu, Jul 28, 2011 at 11:17 AM, Deborah Dahl
>> <dahl@conversational-technologies.com> wrote:
>>> On today's call we talked about the general process of setting
>> parameters
>>> for recognition. In my proposal
>>>
>>
> (http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jun/0086.h
>> tml)
>>> I had suggested that we might want to pick a couple of very
> frequently
>> set
>>> parameters (e.g. grammar and language) and allow them to be set
>> directly as
>>> parameters of the "start recognition" method, as a type of
> convenience
>>> syntax. We agreed during the call that this was not necessary, and
>> agreed
>>> that all the parameters should be explicitly set on the recognition
>> object,
>>> e.g. something like "recognizer.endpointdetection(true)". However,
>> this
>>> raised the question of what happens when parameters are set while a
>>> recognition is in progress. Bjorn's suggestion was to have an
>>> "updateParameters" method that is invoked after the parameter setting
>>> function is called to actually cause the parameters to take effect on
>> the
>>> recognition object. Another option is to distinguish parameters that
>> take
>>> effect immediately, like changing the grammar, from parameters that
>> take
>>> effect only when the next recognition occurs (like maxnbest).
>>> We also discussed setting multiple parameters and whether there
> should
>> be a
>>> way to set several parameters in one call, as in this example that
>> Olli
>>> typed into irc: setParameters({ param1: value, param2: value2}). This
>> might
>>> be convenient, but Bjorn pointed out that it isn't done in any HTML
>> API's.
>>> I'm hoping to update my proposal and sent it out again next week, so
>> any
>>> discussion on the list in the meantime would be helpful. If anyone
> who
>> was
>>> on the call today has anything to add to this summary, that would be
>>> helpful, too.
>>> Debbie
>>>
>>>
>>>
>>
>>
>>
>> --
>> Bjorn Bringert
>> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
>> Palace Road, London, SW1W 9TQ
>> Registered in England Number: 3977902
>>
>>
>
>
>
> --
> Bjorn Bringert
> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
> Palace Road, London, SW1W 9TQ
> Registered in England Number: 3977902
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Thursday, 28 July 2011 20:45:33 UTC