RE: "Protocol" requirement - Cancel request

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

Received on Monday, 13 December 2010 20:11:18 UTC