Re: "Protocol" requirement - Cancel request

I see this as equivalent to the user starting a large download and
then canceling it, or opening a large web page over a slow connection
and then navigating to a different page on the same server. As far as
I know, HTTP provides no mechanism for canceling such requests other
than closing the connection. If that was not considered desirable or
practical in HTTP, I don't see why it would be necessary (or even
feasible) for us to solve the problem for speech.

/Bjorn

On Mon, Dec 13, 2010 at 8:10 PM, Young, Milan <Milan.Young@nuance.com> wrote:
> Persistent connections are effectively standard in modern HTTP communication, and definitely part of "best practice".  This methodology requires that requests to be serviced in serial.  So any uncompleted responses would effectively block new requests.
>
> I'm also not in agreement that we can ignore the performance implications.  For example, let's say a user is reviewing their morning email with a smart phone.  They open the message, listen to the first few sentences, and either mark it for follow-up or delete.  (At least this is how I work!)  This would create a huge backlog of rendering if there were no way to cancel the underlying requests.
>
> Thanks
>
>
> -----Original Message-----
> From: Bjorn Bringert [mailto:bringert@google.com]
> Sent: Monday, December 13, 2010 2:27 AM
> To: Young, Milan
> Cc: public-xg-htmlspeech@w3.org
> Subject: Re: "Protocol" requirement - Cancel request
>
> This generally seems reasonable to be, but I would change the last
> sentence of the description to: "For example, the web app must be able
> to interrupt playback of synthesized speech and capture of audio for
> speech recognition."
>
> It shouldn't matter to the web application whether it actually
> interrupts the synthesis or recognition, since what matters to the
> application's user-visible behavior is just the audio output and
> input. Requiring interrupting the speech processing itself would
> restrict the design space unnecessarily, with the only benefit of some
> bandwidth and processing savings.
>
> I also dropped the "if speech is detected" part, since we already have
> a barge-in requirement, and since web apps may want to interrupt audio
> output for reasons other than barge-in.
>
> /Bjorn
>
> On Fri, Dec 10, 2010 at 8:50 PM, Young, Milan <Milan.Young@nuance.com> wrote:
>> Summary - Web applications must be able to cancel speech requests which have
>> not completed.
>>
>>
>>
>> Description - This requirement does not imply that the UA or SS behave as if
>> the operation never occurred, only that continued processing terminates on a
>> reasonable timeline once the cancel request has been received.  This feature
>> is necessary for common speech operations like bargein.  For example, the
>> web app must be able to interrupt synthesis if speech is detected, and must
>> be able to terminate speech detection if the user doesn't respond in a
>> timely manner.
>>
>>
>
>
>
> --
> 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 Tuesday, 14 December 2010 12:39:26 UTC