Subject: [Speechsc] Recognizer queueing versus synthesizer queueing

From: "David R. Oran" <[email-masked]>
Date: Fri, 3 Jun 2005 10:16:40 -0400

For some reason that escapes me these work completely differently.

The reasons may be historical, or possibly because we thought  
queueing of requests processing media input were different from  
requests processing media output.

To refresh memory, SPEAK requests are queued when the client issues  
one while a current SPEAK is active. If the current request is  
canceled for any reason (stop, cancel-on-barge-in, etc.) the pending  
SPEAK requests are nuked, and the completion response for the  
cancelled SPEAK contains a header with the request id's of the other  
requests in the queue that are now history.

In RECOGNIZE, there is a header (cancel-if-queue) saying whether or  
not  to cancel the current request if the client tries to queue  
another one. If a request is cancelled, the pending requests are also  
canceled but each returns a separate completion event. For some  
reason this header is defined as mandatory rather than having a  
default value.

It seems at a minimum inelegant, to have this disparate machinery,  
and quite possibly a pain for servers which have a single scheduler  
implementation for their different resources to have to implement two  
entirely different schemes, not to mention clients which really  
should be simple and not have to worry about this kind of inconsistency.

If it's too late to change this, I suppose we can live with it.

If the WG will entertain a technical change, let me suggest that the  
other resources adopt the scheduling scheme used by SPEAK, since it's  
simpler, fully general, and well-described in the spec (the recognize  
scheme has some pretty tortured language to explain what's supposed  
to happen). If we do this, the cancel-on-queue header goes away and  
the active-request-ids header gets adopted by the other resources.

I'd probably move the material on request queueing to the common  
protocol section if we go this route, rather than repeating all the  
stuff in each resource.

Please respond with views, because I don't want to adopt such a  
change lightly.

Dave.

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Dave Burke" <[email-masked]>
Date: Fri, 3 Jun 2005 16:27:29 +0100

It's probably worth pointing out that SPEAK and RECOGNIZE are not really 
anti-symmetric since (a) RECOGNIZE requests typically require the audio 
input to be synchronised with the recognition request and (b) subsequent 
recognition actions normally depend on the results of previous recognition 
action(s).

I don't think queuing of RECOGNIZE requests is useful and by removing it 
altogether we also get consistency with RECORD.

Dave

----- Original Message ----- 
From: "David R. Oran" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 03, 2005 3:16 PM
Subject: [Speechsc] Recognizer queueing versus synthesizer queueing

> The reasons may be historical, or possibly because we thought  queueing of 
> requests processing media input were different from  requests processing 
> media output.
>
> To refresh memory, SPEAK requests are queued when the client issues  one 
> while a current SPEAK is active. If the current request is  canceled for 
> any reason (stop, cancel-on-barge-in, etc.) the pending  SPEAK requests 
> are nuked, and the completion response for the  cancelled SPEAK contains a 
> header with the request id's of the other  requests in the queue that are 
> now history.
>
> In RECOGNIZE, there is a header (cancel-if-queue) saying whether or  not 
> to cancel the current request if the client tries to queue  another one. 
> If a request is cancelled, the pending requests are also  canceled but 
> each returns a separate completion event. For some  reason this header is 
> defined as mandatory rather than having a  default value.
>
> It seems at a minimum inelegant, to have this disparate machinery,  and 
> quite possibly a pain for servers which have a single scheduler 
> entirely different schemes, not to mention clients which really  should be 
> simple and not have to worry about this kind of inconsistency.
>
> scheme has some pretty tortured language to explain what's supposed  to 
> happen). If we do this, the cancel-on-queue header goes away and  the 
> active-request-ids header gets adopted by the other resources.
>
> I'd probably move the material on request queueing to the common  protocol 
> section if we go this route, rather than repeating all the  stuff in each 
> resource.
>
> Please respond with views, because I don't want to adopt such a  change 
> lightly.
>
> Dave.
>

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 3 Jun 2005 11:45:35 -0400

On Jun 3, 2005, at 11:27 AM, Dave Burke wrote:

> It's probably worth pointing out that SPEAK and RECOGNIZE are not  
> really anti-symmetric since (a) RECOGNIZE requests typically  
> require the audio input to be synchronised with the recognition  
> request and (b) subsequent recognition actions normally depend on  
> the results of previous recognition action(s).
>
> I don't think queuing of RECOGNIZE requests is useful and by  
> removing it altogether we also get consistency with RECORD.
>
That works for me. The current machinery for recognize queueing is,  
well, peculiar, and if we don't need it I'd just as soon get rid of it.

Let's see how others feel first.

Dave.

> Dave
>
> ----- Original Message ----- From: "David R. Oran" <[email-masked]>
> To: <[email-masked]>
>> To refresh memory, SPEAK requests are queued when the client  
>> issues  one while a current SPEAK is active. If the current  
>> request is  canceled for any reason (stop, cancel-on-barge-in,  
>> etc.) the pending  SPEAK requests are nuked, and the completion  
>> response for the  cancelled SPEAK contains a header with the  
>> request id's of the other  requests in the queue that are now  
>> history.
>>
>> In RECOGNIZE, there is a header (cancel-if-queue) saying whether  
>> or  not to cancel the current request if the client tries to  
>> queue  another one. If a request is cancelled, the pending  
>> requests are also  canceled but each returns a separate completion  
>> event. For some  reason this header is defined as mandatory rather  
>> than having a  default value.
>>
>> It seems at a minimum inelegant, to have this disparate  
>> machinery,  and quite possibly a pain for servers which have a  
>> single scheduler implementation for their different resources to  
>> have to implement two entirely different schemes, not to mention  
>> clients which really  should be simple and not have to worry about  
>> this kind of inconsistency.
>>
>> If the WG will entertain a technical change, let me suggest that  
>> the other resources adopt the scheduling scheme used by SPEAK,  
>> since it's simpler, fully general, and well-described in the spec  
>> (the recognize scheme has some pretty tortured language to explain  
>> what's supposed  to happen). If we do this, the cancel-on-queue  
>> header goes away and  the active-request-ids header gets adopted  
>> by the other resources.
>>
>> protocol section if we go this route, rather than repeating all  
>> the  stuff in each resource.
>>