Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Choosing to use simple VoiceXML and moving the logic server side is a fairly common practice. Pros/Cons below.</p> <p>Server-side logic</p> <ul> <li>Often difficult to get retry counters to perform the way you want if you are also performing input validation (valid for grammar, but not for host or other validation logic)</li> <li>Better programming language/toolkits for making logical descriptions (I'm not a fan of JavaScript, but even if you like JavaScript, you tend to have to create a lot of forms to get the flow control you want). </li> <li>Usually easier to debug. Step through logical decisions and access to logging tools.</li> <li>Usually easier to create reusable components that use parameters to alter component behavior.</li> </ul> <p>Client side logic</p> <ul> <li>Usually more scalable. VoiceXML browsers tend to use a large amount of their resources compiling and processing pages. One larger page will typically do better than a variety of smaller pages. However, platforms vary significantly and your size may make this negligible. </li> <li>Better chance of using static pages. Many platforms have highly optimized caches (more than just fetched data). Like above may only matter if you have 100s of ports per device or 1000s of ports hitting a server. </li> </ul> <p>Mixing and matching isn't bad until somebody requests some sort of global behavior change. You may be making the change in multiple places. Debugging techniques will also vary so it may complicate your support paths (e.g. looking in browser logs versus server logs to see what happened on a call).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload