On 8/3/05, Shane Smith <[EMAIL PROTECTED]> wrote: > Folks, > > I'd like to suggest the following addition to RDC's and see what is > thought of it. In many cases, voice applications will have to perform > some sort of client side code prior to submitting back to the server. > Yes, I realize that the whole idea is to keep logic on the server > side, and this isn't specifically breaking that rule. > <snip/> > > All are valid children of <filled>. Yes, the developer now has the > opportunity to break the 'style' of RDC's (prompt, get input, go back > to the server) but also allows for much more robust applications, such > as a simple audio cue signaling I've heard something. When you mix > this into fetchaudio properties, you can see why a server round-trip > for an audio prompt is unworkable. > > Thanks, and thoughts? <snap/>
Sounds very good. Extending the config to do more has been on the to-do list. I won't get any cycles this week, do you want to propose a patch to fsm-* tag files? We now have a RDC Taglib entry in bugzilla [ http://issues.apache.org/bugzilla/ ] - if you do propose a patch, please file under Taglibs and choose component "RDC Taglib". On a related note, as pointed out briefly in the earlier thread, there is no binding 'style' of RDCs or insistence that there should be a round trip every so often. The binding RDC bits are the public contracts which allow aggregation and composition, more on that is here [ http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials ]. > > -Shane Smith -Rahul
