Subject: RE: [Speechsc] Managing big grammars

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Fri, 10 Jun 2005 16:09:25 -0700

I would say that a common cache amoung a farm of MRCP servers to
optimize compilations would be a nice server side optimization and
shouldn't affect the MRCP protocol.
 
my 2c.
Sarvi

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Corby Anderson
	Sent: Friday, June 10, 2005 11:52 AM
	To: [email-masked]
	Subject: Re: [Speechsc] Managing big grammars

	Option #1 seems like a step in the right direction, but having
multi-server re-use would make it even more useful. Option #1 as worded
implies that each MRCP server would have to compile grammar "X" the
first time it's used;  I'm suggesting that we try and make one MRCP
server's compilation efforts useful to other MRCP servers (as long as
they're the same vendor).  The use case I have in mind is a "farm" of
recognition servers -- and when we compile one of these Large grammars
(grammar "X"), it would be great to store it in some common storage area
so that other MRCP servers could check for its existence and load the
binary.  
	It isn't necessary to have a standard compiled grammar format --
it's just necessary to have a standard way to reference them.  In a
server farm environment containing multiple vendors' MRCP servers,
wouldn't the client know (or couldn't it discover during session setup)
which kind of server it was connecting to and so adjust the
query/compile uri accordingly?  I envision something along the lines of:

		MRCP/2.0 82 QUERY-GRAMMAR 123456
		Compiled-Grammar-URI:
http://grammar-resource/<insert_vendor_here>/query?name=<grammar_name>

		MRCP/2.0 507 COMPILE-GRAMMAR 123654
		Compiled-Grammar-URI:
http://grammar-resource/<insert_vendor_here>/store?name=<grammar_name>
		Content-type: application/srgs+xml
		Content-Length: 176
		
		<?xml version="1.0" (etc.)

	Where the "grammar-resource" would be simple and general enough
to be implemented by either the client or the vendor.
	
	Corby Anderson
	Tellme Networks, Inc.
	
	Shanmugham, Saravanan wrote: 

		I agree, the issue is that there is no standard for
compilation and
		compiled grammar format.  I am not sure a
COMPILE-GRAMMAR method is the
		solution to this. 
		
		The aim of compilation is to accelarate customer
response when dealing
		with large-grammars.
		A few ways to achieve the above, like I mentioned
earlier are,
		   1. The MRCP server could implement an optimization
for large grammars
		that leverages the grammar caching mechanism and its
capabilities. That
		is when they cache a grammar URI, they also store the
compiled version
		of the grammar. They could do this in a vendor specific
compiled format.
		Large grammars are usually not dynamic and hence the
caching mechanims
		should work reasonably well for this.
		   2. Have the MRCP client point to
pre-compiled-grammars so that when
		the MRCP server goes and fetches it the large-grammar is
already
		compiled. There is the problem of making sure the
compiled
		grammar(vendor-specific) matches the specific
recognition engine used.
		This is difficult to manage in a multivendor deployment.
		   3. Compile and store the grammars on the MRCP server
ahead of time
		during deployments. And then refer to these compiled
grammars on the
		MRCP server. This would have its own limitations, but
would be workable
		in many cases/deployments.

		We could add the text for the first above bullet into
the MRCPv2
		specification if no one has any objects to it.
		
		Thanks,
		
		     -----Original Message-----
		     From: [email-masked] 
		     [mailto:[email-masked]] On Behalf Of
Qiru Zhou
		     Sent: Wednesday, June 08, 2005 2:17 PM
		     To: Corby Anderson
		     Cc: [email-masked]
		     Subject: Re: [Speechsc] Managing big grammars
		     
		     I think the problem here is there is no standard
for 
		     compiled grammar format. This is a vendor
implementation 
		     specific which is not inter-operable across
different 
		     vendors. I agree that pre-compiled large grammars
can 
		     improve system response and processing efficiency.
But I 
		     don't know if this should be the part of standard.
Same 
		     for cache, it is an implementation specific issue.
Another 
		     practice on this issue is to pre load and archive
large 
		     grammar in recognizer (i.e., add ARCHIVE-GRAMMAR
method).
		     
		     -- Qiru
		     
		     Corby Anderson wrote:
		     > One feature that I'd like a COMPILE-GRAMMAR
method to 
		     provide is the 
		     > ability to specify common back-end storage (like
Sarvi 
		     mentioned) so 
		     > that compiling a Large Grammar one time could
make it 
		     available to 
		     > other MRCP servers via the Compiled-Grammar-URI
that 
		     Klaus suggested.  
		     > It would be especially useful to us if the
*client* 
		     could specify the 
		     > URI where the grammar should be stored.  This
would 
		     permit clients to 
		     > use grammar names that are meaningful to the
client.  
		     (The example for 
		     > Personal-Grammar-URI seems like the grammar name
is 
		     specified by the 
		     > client, but it's worth spelling out.)
		     > 
		     > To round out the utility of a feature like this,
we'd 
		     need some way to 
		     > determine if a grammar had already been compiled.
Since 
		     we're talking 
		     > about URIs, the client could just do a HEAD on
the 
		     grammar to see if 
		     > it exists -- but does the client always have
access to back-end 
		     > resources in this way?  If not, then a
QUERY-GRAMMAR 
		     method which 
		     > takes a Compiled-Grammar-URI header could provide
this 
		     capability.
		     > 
		     > Corby Anderson
		     > Tellme Networks, Inc.
		     > 
		     > 
		     > Reifenrath, Klaus wrote:
		     > 
		     >> I agree.
		     >> BUT unfortunately there is no MRCPv2 interface
to just 
		     compile a 
		     >> grammar. So grammar compilation needs to be done
with 
		     vendor specific 
		     >> tools or APIs.
		     >> We could add a new method (allowed only in idle
state):
		     >> COMPILE-GRAMMAR
		     >> that requires the header field
		     >> Compiled-Grammar-URI
		     >> that specifies the location of the compiled
grammar (like 
		     >> Personal-Grammar-URI).
		     >> Is it too late to add this simple optional
method?
		     >>
		     >> Klaus
		     >>
		     >> -----Original Message-----
		     >> From: Shanmugham, Saravanan
[mailto:[email-masked]] 
		     Sent: Dienstag, 
		     >> 7. Juni 2005 21:09
		     >> To: Corby Anderson; [email-masked]
		     >> Subject: RE: [Speechsc] Managing big grammars
		     >>
		     >> Sorry for the late reply. The way I think this
should 
		     be addressed is 
		     >> to have support for compiled grammars as URI.
All Large or Huge 
		     >> grammars are going to be URI referenced and
never 
		     embedded in a DEFINE grammar.
		     >> This means that the URI could point to compiled
grammar file.
		     >>
		     >> Another way is to use the chache capability.
When you access a 
		     >> grammar through HTTP is to cache it. In general
instead 
		     of caching of 
		     >> the XML grammar you could decide to cache the
compiled version 
		     >> instead. This would mean that you might do an
initial 
		     DEFINE-GRAMMAR 
		     >> to force a compile of the grammar and future
references to that 
		     >> grammar URI would hit the cache and hence the
compiled version.
		     >>
		     >> Sarvi
		     >>
		     >>     -----Original Message-----
		     >>     From: [email-masked]     
		     >> [mailto:[email-masked]] On Behalf Of
Corby Anderson
		     >>     Sent: Thursday, May 26, 2005 2:11 PM
		     >>     To: [email-masked]
		     >>     Subject: [Speechsc] Managing big grammars
		     >>         What are folks' thoughts on how we could
manage big     
		     >> grammars with MRCP?
		     >>         There are two usage cases that I'm
interested 
		     in: a Large     
		     >> Grammar that takes several seconds to compile,
and a 
		     Jumbo     Grammar 
		     >> that takes many many minutes to compile.  A
Large     
		     Grammar might 
		     >> contain several hundred or thousand entries.
A 
		     Jumbo Grammar 
		     >> might contain hundreds of thousands of entries.
		     >>         For a Jumbo Grammar, there's no way that
a user 
		     can wait     
		     >> for a grammar to be uploaded and compiled via
the     
		     DEFINE-GRAMMAR 
		     >> or RECOGNIZE methods.  A grammar that large
needs to be 
		     >> pre-compiled so that the DEFINE-GRAMMAR or     
		     RECOGNIZE method can 
		     >> simply load the grammar binary.
		     >>         For a Large Grammar, it might be okay to
make 
		     one user     
		     >> wait a few seconds for the grammar to compile --
but it 
		         would be a 
		     >> big win if that compiled grammar were stored
with a 
		     known name so 
		     >> that /subsequent/ uses of the same     grammar
don't 
		     have to pay the 
		     >> same compilation penalty.
		     >>         Our current speech recognition vendor's
api 
		     provides     
		     >> methods for checking for the existence of a
dynamic     
		     grammar, and 
		     >> for compiling a new grammar (named as the
client 
		     specifies). The 
		     >> api also provides a powerful and     flexible
way to 
		     manage these 
		     >> stored grammars.  Is there     some
MRCP-friendly way 
		     for dealing with 
		     >> these types of     grammars?  If not, then is
one being 
		     considered?
		     >>         Corby Anderson
		     >>     Tellme Networks, Inc.
_______________________________________________
		     >>     Speechsc mailing list
		     >>     [email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc
		     >>    
		     >> _______________________________________________
		     >> Speechsc mailing list
		     >> [email-masked]
		     >> https://www1.ietf.org/mailman/listinfo/speechsc
		     >>  
		     >>
		     > 
		     > _______________________________________________
		     > Speechsc mailing list
		     > [email-masked]
		     > https://www1.ietf.org/mailman/listinfo/speechsc

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 10 Jun 2005 19:42:00 -0400

<chair hat off>
I agree with Sarvi - I have not heard a compelling argument for the  
need to extend the protocol for this.
</chair hat off>

Dave.

On Jun 10, 2005, at 7:09 PM, Shanmugham, Saravanan wrote:

> From: [email-masked] [mailto:[email-masked]]  
> On Behalf Of Corby Anderson
> multi-server re-use would make it even more useful. Option #1 as  
> worded implies that each MRCP server would have to compile grammar  
> "X" the first time it's used;  I'm suggesting that we try and make  
> one MRCP server's compilation efforts useful to other MRCP servers  
> (as long as they're the same vendor).  The use case I have in mind  
> is a "farm" of recognition servers -- and when we compile one of  
> these Large grammars (grammar "X"), it would be great to store it  
> in some common storage area so that other MRCP servers could check  
> for its existence and load the binary.
> wouldn't the client know (or couldn't it discover during session  
> setup) which kind of server it was connecting to and so adjust the  
> Compiled-Grammar-URI: http://grammar-resource/<insert_vendor_here>/ 
> query?name=<grammar_name>
>
>
> Compiled-Grammar-URI: http://grammar-resource/<insert_vendor_here>/ 
> store?name=<grammar_name>
> Where the "grammar-resource" would be simple and general enough to  
> be implemented by either the client or the vendor.
>
> Corby Anderson
> Tellme Networks, Inc.
>
>> I agree, the issue is that there is no standard for compilation  
>> and compiled grammar format. I am not sure a COMPILE-GRAMMAR  
>> method is the solution to this. The aim of compilation is to  
>> accelarate customer response when dealing with large-grammars. A  
>> few ways to achieve the above, like I mentioned earlier are, 1.  
>> The MRCP server could implement an optimization for large grammars  
>> that leverages the grammar caching mechanism and its capabilities.  
>> That is when they cache a grammar URI, they also store the  
>> compiled version of the grammar. They could do this in a vendor  
>> specific compiled format. Large grammars are usually not dynamic  
>> and hence the caching mechanims should work reasonably well for  
>> this. 2. Have the MRCP client point to pre-compiled-grammars so  
>> that when the MRCP server goes and fetches it the large-grammar is  
>> already compiled. There is the problem of making sure the compiled  
>> grammar(vendor-specific) matches the specific recognition engine  
>> used. This is difficult to manage in a multivendor deployment. 3.  
>> Compile and store the grammars on the MRCP server ahead of time  
>> during deployments. And then refer to these compiled grammars on  
>> the MRCP server. This would have its own limitations, but would be  
>> workable in many cases/deployments. We could add the text for the  
>> first above bullet into the MRCPv2 specification if no one has any  
>> objects to it. Thanks, -----Original Message----- From: speechsc- 
>> [email-masked] [mailto:[email-masked]] On Behalf Of  
>> Qiru Zhou Sent: Wednesday, June 08, 2005 2:17 PM To: Corby  
>> Anderson Cc: [email-masked] Subject: Re: [Speechsc] Managing  
>> big grammars I think the problem here is there is no standard for  
>> compiled grammar format. This is a vendor implementation specific  
>> which is not inter-operable across different vendors. I agree that  
>> pre-compiled large grammars can improve system response and  
>> processing efficiency. But I don't know if this should be the part  
>> of standard. Same for cache, it is an implementation specific  
>> issue. Another practice on this issue is to pre load and archive  
>> large grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). --  
>> Qiru Corby Anderson wrote: > One feature that I'd like a COMPILE- 
>> GRAMMAR method to provide is the > ability to specify common back- 
>> end storage (like Sarvi mentioned) so > that compiling a Large  
>> Grammar one time could make it available to > other MRCP servers  
>> via the Compiled-Grammar-URI that Klaus suggested. > It would be  
>> especially useful to us if the *client* could specify the > URI  
>> where the grammar should be stored. This would permit clients to >  
>> use grammar names that are meaningful to the client. (The example  
>> for > Personal-Grammar-URI seems like the grammar name is  
>> specified by the > client, but it's worth spelling out.) > > To  
>> round out the utility of a feature like this, we'd need some way  
>> to > determine if a grammar had already been compiled. Since we're  
>> talking > about URIs, the client could just do a HEAD on the  
>> grammar to see if > it exists -- but does the client always have  
>> access to back-end > resources in this way? If not, then a QUERY- 
>> GRAMMAR method which > takes a Compiled-Grammar-URI header could  
>> provide this capability. > > Corby Anderson > Tellme Networks,  
>> Inc. > > > Reifenrath, Klaus wrote: > >> I agree. >> BUT  
>> unfortunately there is no MRCPv2 interface to just compile a >>  
>> grammar. So grammar compilation needs to be done with vendor  
>> specific >> tools or APIs. >> We could add a new method (allowed  
>> only in idle state): >> COMPILE-GRAMMAR >> that requires the  
>> header field >> Compiled-Grammar-URI >> that specifies the  
>> location of the compiled grammar (like >> Personal-Grammar-URI).  
>> >> Is it too late to add this simple optional method? >> >> Klaus  
>> >> >> -----Original Message----- >> From: Shanmugham, Saravanan  
>> [mailto:[email-masked]] Sent: Dienstag, >> 7. Juni 2005 21:09 >>  
>> To: Corby Anderson; [email-masked] >> Subject: RE: [Speechsc]  
>> Managing big grammars >> >> Sorry for the late reply. The way I  
>> think this should be addressed is >> to have support for compiled  
>> grammars as URI. All Large or Huge >> grammars are going to be URI  
>> referenced and never embedded in a DEFINE grammar. >> This means  
>> that the URI could point to compiled grammar file. >> >> Another  
>> way is to use the chache capability. When you access a >> grammar  
>> through HTTP is to cache it. In general instead of caching of >>  
>> the XML grammar you could decide to cache the compiled version >>  
>> instead. This would mean that you might do an initial DEFINE- 
>> GRAMMAR >> to force a compile of the grammar and future references  
>> to that >> grammar URI would hit the cache and hence the compiled  
>> version. >> >> Sarvi >> >> -----Original Message----- >> From:  
>> [email-masked] >> [mailto:[email-masked]] On  
>> Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM  
>> >> To: [email-masked] >> Subject: [Speechsc] Managing big  
>> grammars >> What are folks' thoughts on how we could manage big >>  
>> grammars with MRCP? >> There are two usage cases that I'm  
>> interested in: a Large >> Grammar that takes several seconds to  
>> compile, and a Jumbo Grammar >> that takes many many minutes to  
>> compile. A Large Grammar might >> contain several hundred or  
>> thousand entries. A Jumbo Grammar >> might contain hundreds of  
>> thousands of entries. >> For a Jumbo Grammar, there's no way that  
>> a user can wait >> for a grammar to be uploaded and compiled via  
>> the DEFINE-GRAMMAR >> or RECOGNIZE methods. A grammar that large  
>> needs to be >> pre-compiled so that the DEFINE-GRAMMAR or  
>> RECOGNIZE method can >> simply load the grammar binary. >> For a  
>> Large Grammar, it might be okay to make one user >> wait a few  
>> seconds for the grammar to compile -- but it would be a >> big win  
>> if that compiled grammar were stored with a known name so >> that / 
>> subsequent/ uses of the same grammar don't have to pay the >> same  
>> compilation penalty. >> Our current speech recognition vendor's  
>> api provides >> methods for checking for the existence of a  
>> dynamic grammar, and >> for compiling a new grammar (named as the  
>> client specifies). The >> api also provides a powerful and  
>> flexible way to manage these >> stored grammars. Is there some  
>> MRCP-friendly way for dealing with >> these types of grammars? If  
>> not, then is one being considered? >> Corby Anderson >> Tellme  
>> Networks, Inc. >> _______________________________________________  
>> >> Speechsc mailing list >> [email-masked] >> https:// 
>> www1.ietf.org/mailman/listinfo/speechsc >> >>  
>> _______________________________________________ >> Speechsc  
>> mailing list >> [email-masked] >> https://www1.ietf.org/mailman/ 
>> listinfo/speechsc >> >> > >  
>> _______________________________________________ > Speechsc mailing  
>> list > [email-masked] > https://www1.ietf.org/mailman/listinfo/ 
>> speechsc

---

From: "Dave Burke" <[email-masked]>
Date: Sat, 11 Jun 2005 16:41:55 +0100

I agree. Grammar compilation, caching, and sharing is a problem for the MRCP server. Exposing this in the protocol puts unnecessary complexity on the client. For example, the client needs to download grammars, implement its own HTTP caching, checksum algorithms (some way of not having to push huge data to the MRCP server to query) etc.

So I vote for point 1 below and include in the text that an MRCP server could also, as an optimisation, implement a centralised common cache shared across multiple MRCP servers.

Dave
  ----- Original Message ----- 
  From: Shanmugham, Saravanan 
  To: Corby Anderson ; [email-masked] 
  Sent: Saturday, June 11, 2005 12:09 AM
  Subject: RE: [Speechsc] Managing big grammars

  I would say that a common cache amoung a farm of MRCP servers to optimize compilations would be a nice server side optimization and shouldn't affect the MRCP protocol.

  my 2c.
  Sarvi

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Corby Anderson
    Sent: Friday, June 10, 2005 11:52 AM
    To: [email-masked]
    Subject: Re: [Speechsc] Managing big grammars

    Option #1 seems like a step in the right direction, but having multi-server re-use would make it even more useful. Option #1 as worded implies that each MRCP server would have to compile grammar "X" the first time it's used;  I'm suggesting that we try and make one MRCP server's compilation efforts useful to other MRCP servers (as long as they're the same vendor).  The use case I have in mind is a "farm" of recognition servers -- and when we compile one of these Large grammars (grammar "X"), it would be great to store it in some common storage area so that other MRCP servers could check for its existence and load the binary.  
    It isn't necessary to have a standard compiled grammar format -- it's just necessary to have a standard way to reference them.  In a server farm environment containing multiple vendors' MRCP servers, wouldn't the client know (or couldn't it discover during session setup) which kind of server it was connecting to and so adjust the query/compile uri accordingly?  I envision something along the lines of:

      MRCP/2.0 82 QUERY-GRAMMAR 123456
      Compiled-Grammar-URI: http://grammar-resource/<insert_vendor_here>/query?name=<grammar_name>

      MRCP/2.0 507 COMPILE-GRAMMAR 123654
      Compiled-Grammar-URI: http://grammar-resource/<insert_vendor_here>/store?name=<grammar_name>
      Content-type: application/srgs+xml
      Content-Length: 176

    Where the "grammar-resource" would be simple and general enough to be implemented by either the client or the vendor.

    Corby Anderson
    Tellme Networks, Inc.

    Shanmugham, Saravanan wrote: 
I agree, the issue is that there is no standard for compilation and
compiled grammar format.  I am not sure a COMPILE-GRAMMAR method is the
solution to this. 

The aim of compilation is to accelarate customer response when dealing
with large-grammars.
A few ways to achieve the above, like I mentioned earlier are,
   1. The MRCP server could implement an optimization for large grammars
that leverages the grammar caching mechanism and its capabilities. That
is when they cache a grammar URI, they also store the compiled version
of the grammar. They could do this in a vendor specific compiled format.
Large grammars are usually not dynamic and hence the caching mechanims
should work reasonably well for this.
   2. Have the MRCP client point to pre-compiled-grammars so that when
the MRCP server goes and fetches it the large-grammar is already
compiled. There is the problem of making sure the compiled
grammar(vendor-specific) matches the specific recognition engine used.
This is difficult to manage in a multivendor deployment.
   3. Compile and store the grammars on the MRCP server ahead of time
during deployments. And then refer to these compiled grammars on the
MRCP server. This would have its own limitations, but would be workable
in many cases/deployments.

We could add the text for the first above bullet into the MRCPv2
specification if no one has any objects to it.

Thanks,

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Qiru Zhou
     Sent: Wednesday, June 08, 2005 2:17 PM
     To: Corby Anderson
     Cc: [email-masked]
     Subject: Re: [Speechsc] Managing big grammars
     
     I think the problem here is there is no standard for 
     compiled grammar format. This is a vendor implementation 
     specific which is not inter-operable across different 
     vendors. I agree that pre-compiled large grammars can 
     improve system response and processing efficiency. But I 
     don't know if this should be the part of standard. Same 
     for cache, it is an implementation specific issue. Another 
     practice on this issue is to pre load and archive large 
     grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method).
     
     -- Qiru
     
     Corby Anderson wrote:
     > One feature that I'd like a COMPILE-GRAMMAR method to 
     provide is the 
     > ability to specify common back-end storage (like Sarvi 
     mentioned) so 
     > that compiling a Large Grammar one time could make it 
     available to 
     > other MRCP servers via the Compiled-Grammar-URI that 
     Klaus suggested.  
     > It would be especially useful to us if the *client* 
     could specify the 
     > URI where the grammar should be stored.  This would 
     permit clients to 
     > use grammar names that are meaningful to the client.  
     (The example for 
     > Personal-Grammar-URI seems like the grammar name is 
     specified by the 
     > To round out the utility of a feature like this, we'd 
     need some way to 
     > determine if a grammar had already been compiled.  Since 
     we're talking 
     > about URIs, the client could just do a HEAD on the 
     grammar to see if 
     > it exists -- but does the client always have access to back-end 
     > resources in this way?  If not, then a QUERY-GRAMMAR 
     method which 
     > takes a Compiled-Grammar-URI header could provide this 
     capability.
     > 
     > Corby Anderson
     > Tellme Networks, Inc.
     > 
     > 
     > Reifenrath, Klaus wrote:
     > 
     >> I agree.
     >> BUT unfortunately there is no MRCPv2 interface to just 
     compile a 
     >> grammar. So grammar compilation needs to be done with 
     vendor specific 
     >> tools or APIs.
     >> We could add a new method (allowed only in idle state):
     >> COMPILE-GRAMMAR
     >> that specifies the location of the compiled grammar (like 
     >> Personal-Grammar-URI).
     >> Is it too late to add this simple optional method?
     >>
     >> Klaus
     >>
     >> From: Shanmugham, Saravanan [mailto:[email-masked]] 
     Sent: Dienstag, 
     >> Sorry for the late reply. The way I think this should 
     be addressed is 
     >> to have support for compiled grammars as URI. All Large or Huge 
     >> grammars are going to be URI referenced and never 
     >> This means that the URI could point to compiled grammar file.
     >>
     >> Another way is to use the chache capability. When you access a 
     >> grammar through HTTP is to cache it. In general instead 
     of caching of 
     >> the XML grammar you could decide to cache the compiled version 
     >> instead. This would mean that you might do an initial 
     DEFINE-GRAMMAR 
     >> to force a compile of the grammar and future references to that 
     >> grammar URI would hit the cache and hence the compiled version.
     >>
     >> Sarvi
     >>
     >>         What are folks' thoughts on how we could manage big     
     >> grammars with MRCP?
     >>         There are two usage cases that I'm interested 
     in: a Large     
     >> Grammar that takes several seconds to compile, and a 
     Jumbo     Grammar 
     >> that takes many many minutes to compile.  A Large     
     Grammar might 
     >> contain several hundred or thousand entries.      A 
     Jumbo Grammar 
     >>         For a Jumbo Grammar, there's no way that a user 
     can wait     
     >> for a grammar to be uploaded and compiled via the     
     DEFINE-GRAMMAR 
     >> or RECOGNIZE methods.  A grammar that large     needs to be 
     RECOGNIZE method can 
     >>         For a Large Grammar, it might be okay to make 
     one user     
     >> wait a few seconds for the grammar to compile -- but it 
         would be a 
     >> big win if that compiled grammar were stored     with a 
     known name so 
     >> that /subsequent/ uses of the same     grammar don't 
     have to pay the 
     >>         Our current speech recognition vendor's api 
     provides     
     >> methods for checking for the existence of a dynamic     
     grammar, and 
     >> for compiling a new grammar (named as the     client 
     specifies). The 
     >> api also provides a powerful and     flexible way to 
     manage these 
     >> stored grammars.  Is there     some MRCP-friendly way 
     for dealing with 
     >> these types of     grammars?  If not, then is one being 
     considered?
     >>     Tellme Networks, Inc.

------------------------------------------------------------------------------

---

From: Corby Anderson <[email-masked]>
Date: Sat, 11 Jun 2005 13:41:00 -0700

Thanks, all, for considering those features.  I appreciate the time you 
spent discussing them -- especially since the spec is so close to 
completion.

So let's quickly revisit the original two usage cases I was interested 
in (Large grammars that might be several thousand lines long and Jumbo 
grammars that might be hundreds of thousands of lines long).  It sounds 
clear that the group's intent is for vendors to provide back-end tools 
for compiling, storing, and referring to Jumbo grammar binaries; so 
Sarvi's option #1 would only apply to the Large grammars.  When the 
client wants to recognize with a Large grammar, it would have to upload 
the grammar source to the MRCP server (which may or may not cache it in 
source and/or binary form -- depending on how/if the vendor chooses to 
implement this optimization).  Would it be appropriate to include a hint 
to the client that the MRCP server has cached the grammar?  For example, 
if a Large grammar is uploaded with DEFINE-GRAMMAR, a header in the 200 
response could indicate that this grammar is cached -- a client could 
use this information to avoid uploading that Large grammar again for 
future recognitions with that grammar on that MRCP server.

The downside, of course, is that it raises cache management issues: how 
long do these things stay in cache, how can a client determine if a 
previously-cached grammar is still in the cache, etc.  All of these are 
surmountable, but I don't have a feel for whether they belong in the 
spec or not.

What does the group think?  If a vendor chooses to implement Large 
grammar caching, should the spec cover supplying hints to the client so 
that the client doesn't have to upload the same (cached) grammar for 
subsequent recogntions?  Even though this would be a vendor-optional 
feature, I think it would common enough that the spec would benefit from 
having a common mechanism to indicate whether a grammar is cached.

Thanks,
Corby Anderson
Tellme Networks, Inc.

Dave Burke wrote:

> I agree. Grammar compilation, caching, and sharing is a problem for 
> the MRCP server. Exposing this in the protocol puts unnecessary 
> complexity on the client. For example, the client needs to download 
> grammars, implement its own HTTP caching, checksum algorithms (some 
> way of not having to push huge data to the MRCP server to query) etc.
>  
> So I vote for point 1 below and include in the text that an MRCP 
> server could also, as an optimisation, implement a centralised common 
> cache shared across multiple MRCP servers.
>  
> Dave
>
>     *From:* Shanmugham, Saravanan <mailto:[email-masked]>
>     *To:* Corby Anderson <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]>
>     *Sent:* Saturday, June 11, 2005 12:09 AM
>     *Subject:* RE: [Speechsc] Managing big grammars
>
>         ------------------------------------------------------------------------
>         *From:* [email-masked]
>         <mailto:[email-masked]>
>         [mailto:[email-masked]] *On Behalf Of *Corby Anderson
>         *Sent:* Friday, June 10, 2005 11:52 AM
>         *To:* [email-masked] <mailto:[email-masked]>
>         *Subject:* Re: [Speechsc] Managing big grammars
>
>         multi-server re-use would make it even more useful. Option #1
>         as worded implies that /each /MRCP server would have to
>         compile grammar "X" the first time it's used;  I'm suggesting
>         that we try and make one MRCP server's compilation efforts
>         useful to other MRCP servers (as long as they're the same
>         vendor).  The use case I have in mind is a "farm" of
>         recognition servers -- and when we compile one of these Large
>         grammars (grammar "X"), it would be great to store it in some
>         common storage area so that other MRCP servers could check for
>         its existence and load the binary. 
>         It isn't necessary to have a standard compiled grammar format
>         -- it's just necessary to have a standard way to reference
>         them.  In a server farm environment containing multiple
>         vendors' MRCP servers, wouldn't the client know (or couldn't
>         it discover during session setup) which kind of server it was
>         connecting to and so adjust the query/compile uri
>         accordingly?  I envision something along the lines of:
>
>         Where the "grammar-resource" would be simple and general
>         enough to be implemented by either the client or the vendor.
>
>         Corby Anderson
>         Tellme Networks, Inc.
>
>     ------------------------------------------------------------------------