Re: "Protocol" requirement - Cancel request

On Tue, Dec 14, 2010 at 5:30 PM, Young, Milan <Milan.Young@nuance.com> wrote:
> Let's take these issues one by one:
>
>  * Is it possible to do this under HTTP - Yes.  All we need is to send a second request that causes the first to stop transmitting.

Yes, this is possible, but I don't know of any other HTTP applications
that do this. The HTML <audio> tag doesn't as far as I know, and it
should have pretty much the exact same use cases as TTS.


>  * Can we use HTTP persistent connections without this feature?  From how I read the spec, responses are sent in serial, so no.

You can still use persistent connections, it's just that you need a
new one after canceling a TTS request. Just like browsers use
persistent connections for getting other resources used in web pages,
even though users sometimes interrupt the download.


>  * Are we introducing performance problems by not doing this?  Sounds like we disagree.  Interested in hearing from others.

I agree that it is a performance problem, but I don't agree that it is
an important performance problem. If it is a important problem, how
come it hasn't been solved for other resources fetched with HTTP in
browsers?

/Bjorn

> -----Original Message-----
> From: Bjorn Bringert [mailto:bringert@google.com]
> Sent: Tuesday, December 14, 2010 4:39 AM
> To: Young, Milan
> Cc: public-xg-htmlspeech@w3.org
> Subject: 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
>



-- 
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 20:26:13 UTC