Re: [vtp-dev] Questions, directions, techie stuff

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

Dominique,

    You are right on the round-tripping.  For the cost of a small amount of
additional network traffic you gain quite a bit of functionality.  The voice
browser can be constrained in resources by the number of ports it hosts,
whether or not ASR or TTS process are running locally, and several other
issues.  Moving the work of the business logic to the application server
provides a nice distribution of work similar to that of the web.

You also make a great point about the pending VXML version change.  The
runtime could easily serve up version 2.1 VXML to one platform and 3.0 to
another from the same deployed application.  That would make migration
within a heterogeneous platform environment, like a large MSP, very simple.
Especially if half your vendors move and the other half are still in
development.

Trip Gilman


On 4/17/09 12:40 PM, "Dominique Boucher" <dominique.boucher@xxxxxxxxxx>
wrote:

> Hi David,
> 
> I would not be too concerned about the round-tripping issue. We have
> used that approach extensively in our applications (both our packaged
> apps and the custom apps we develop for some of our large customers) and
> it scales pretty well. Other companies follow this approach too
> (VoiceObjects, Cisco/Audium, Avaya, Vicorp, etc.). Also, this may ease
> the transition to the upcoming VoiceXML 3.0.
> 
> My 2 cents,
> 
> Dominique Boucher
> Nu Echo Inc.
> http://nugram.nuecho.com | http://www.nuecho.com
> 
> NuGram Platform : the complete grammar solution
> http://twitter.com/nugram
> 
> David Reich wrote:
>> Yes, thanks, Randy, it definitely helps.  It's a bit of a departure from
>> "just doing Voice/CC XML (and SRGS)" but I see where you're heading.  The
>> more I think about it, the idea of a generation layer from the abstraction of
>> the app is not a bad idea, especially because of browser platform subtleties
>> and other interaction models (such as SMS) but my main concern is
>> round-tripping of the generated (browser-consumable) version of the emitted
>> code.  The platform abstraction layer is one idea to tweak that emitted
>> output, but I need to digest the different use cases of consumers of the tool
>> to see how/if it covers most of the cases.  (My work to do ;-)
>> 
>> Thanks again for the prompt feedback.  I'm enjoying getting back into this
>> stuff!
>> 
>> 
>> 
>> David Reich
>> AIT Architect,  Adeptra, Inc.
>>   
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev