Subject: RE: [IPTEL] CPL-03 Comments and Questions

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Nov 2000 22:24:23 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 13, 2000 4:22 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
> 
> This appears to be a very powerful idea.
> 
> A couple of potential drawbacks:
> 1. Reduced performance: scripts can't be entirely pre-parsed, since a
> different fragment may come back from the Perl script every 
> single call;

That depends on the service, of course. If you look at VoiceXML, they handle
this through caching directives that can be placed in the script. These
directives tell the server whether the fetched content can be cached, and
for how long.

> 2. There could be compatibility problems; namely, the Perl 
> script might
> return a fragment using a namespace not supported by the CPL server.

Sure. You return an error in this case (500 class most probably).

> 
> In some cases, there may be simpler ways of achieving the 
> same goal. For
> example, consider the following as a way of addressing your 
> "criminals"
> example:
> 
> <lookup source="http://www.criminals.com/locate.pl" timeout=5">
>   <success>
>     <reject/>
>   </success>
>   <notfound>
>     <lookup source="registration">
>       <success>
>         <proxy/>
>       </success>
>     </lookup>    
>   </notfound>
> </lookup>
> 
> It just uses existing CPL syntax (but it assumes that the 
> originator's URL
> will be passed to the Perl script, which passes back the 
> originator's URL if
> and only if it is the URL of a criminal).

Well, you are modifying the meaning of lookup. In any case, I'm looking for
something far more generic.

> 
> Another possibility would be to add an action to invoke a script that
> returns an arbitrary string, and to add a new string-switch 
> field to look at
> the result of the script. Then you could do something like this:
> 
> <fetch-string 
> source="http://www.phonenumbers.com/classify.pl" timeout=5">
>   <success>
>     <string-switch field="script-result">
>       <string contains="criminal">
>         <reject/>
>       </string>
>       <string contains="telemarketer">
>         <reject/>
>       </string>
>     </string-switch>
>   </success>
>   <notfound>
>     <lookup source="registration">
>       <success>
>         <proxy/>
>       </success>
>     </lookup>    
>   </notfound>
> </lookup>

This could work, but it makes CPL coding far less modular than I would like.
I really like the VoiceXML model where a fetch can actually return an
entirely new script to execute. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 14 Nov 2000 22:41:51 -0500

In the "loading" of scripts via HTTP, is this "stacked"? I.e., if the
loaded script returns, what happens? Does execution continue after the
invocation of the http? Is there a namespace separation (VoiceXML has
variables)? Can there be random jumps from a newly-loaded routine to an
existing subroutine? Can existing subroutines be replaced? What if the
subroutine making the http "call" itself gets replaced? What happens to
CPL predictability if there is a loop of endless retrievals?

Just questions - maybe VoiceXML has solved all of these.

I have to admit to some queasiness to a model that looks suspiciously
like the old "load a new segment" model in early Intel/DOS versions. (It
appears somewhat similar to the "load" statement in Tcl, say, too, with
potentially some of the same unpredictability.)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs