[Asterisk-Users] Newbie IVR question

[Steven Critchfield]

On Mon, 2003-09-08 at 01:19, Tom Forbes wrote:
> Steven Critchfield wrote:
> > On Sun, 2003-09-07 at 00:43, Tom Forbes wrote:
> > 
> >>Steven Critchfield wrote:
> >>
> >>>On Tue, 2003-09-02 at 10:00, listbox at adamsbrothers.com wrote:
> >>>
> >>>
> >>>>php is not just a web scripting language anymore.  it has been used in
> >>>>other ways for quite a while now.  it works nicely from the command line,
> >>>>can be used with ncurses and with gtk.  there are several well-known
> >>>>respectable large projects out there built upon php.  i usually find that
> >>>>php's biggest critics are those who know the least about the language. 
> >>>>however that holds true with pretty much any technology.  linux suffers
> >>>
> >>>>from the same type of critics.
> >>>
> >>>
> >>>Just to point out, I am a php developer. I actually am employed to
> >>>create and maintain a large webapp in php. 
> >>>
> >>>I like the fact that I can take my php or perl scripts and not have to
> >>>change much to them to work in the other language. Well if they are
> >>>simple enough. There is enough well known documented problems with php.
> >>
> >>Such as?
> > 
> > 
> > This is just an example that a co worker submitted recently. Now that
> > bugs is back up I can point to it.
> > http://bugs.php.net/bug.php?id=25281
> > 
> > A fair number of problems seem to be from the developers personalities.
> > This is known in other open source software as well. Take the fact that
> > so many people avoid qmail due to DJB. Monty Widenius of mysql causes
> > people to continually search for something better. 
> 
> So, we're not necessarily talking about functionality problems (real 
> ones anyway), but about personality problems- people who are vocal about 
> their disagreement with the routes that various open source efforts have 
> taken.

Actually there are lots of problems with functionality. My coworker
seems to find all kinds of bugs in php. I've joked with him that he
pushes php too hard since I don't generally run into the bugs when I do
php pages. The link I provided was an example of the developers not
paying attention to members of the group and then breaking features. Php
has a reputation similar to RH in that every time you upgrade you have
to search for what was broken before you deploy. 

> >>>Just saying that because it is used in large projects doesn't change
> >>>whether it is suited to the task. There are enough people on this
> >>>planet, that statistically you will find enough people who refuse to
> >>>admit the are using a square peg for the round hole.
> >>
> >>If we go back to PERL's roots, we find that it was never intended as a 
> >>general, all-purpose language, but one for extracting and formatting 
> >>data. Now it seems as though it's being touted as the cure-all for 
> >>*anything* that requires scripting. PHP's intent, on the other hand was 
> >>a bit more sophisticated. Being a "web-based" scripting languange, it, 
> >>by necessity, had to interface with other components (and do it 
> >>efficiently) in order to acquire, manipulate, and pass data between the 
> >>  user and any backend processes.
> >>
> >>I'm more curious to know what exactly it is about AGI scripting that 
> >>would make PHP an inappropriate choice.
> > 
> > 
> > Perl has always been intended to be glue between processes. 
> 
> You mean, the intent of PERL *has come to be* glue between processes. It 
> wasn't that way in the beginning. I'd venture to say tha that most of 
> what PERL can do today wasn't even a twinkle in its author's eye at the 
> time it was first conceived.

No, it always has been glue. awk and sed are also glue. Perl was
combining the best of awk and sed and then adding in some more. 

> I don't
> > consider it the cure all for everything. While I have used the gtk
> > extensions for php and perl for curiosity, I wouldn't suggest using them
> > for anything that needs to be done on a production system. 
> > 
> > When you consider what it is you are doing, perl seems the perfect
> > choice. AGI is a textual interface to your app, which then must respond
> > in text. This is what perl was written to handle. 
> 
> No, PERL, more accurately, was written to chew through reams of textual 
> data, and produce some kind of formatted output. Consider the definition 
> that appears in the original PERL man page:
> 
> 	Perl is a interpreted language optimized for scanning  arbi-
>       	trary  text  files,  extracting  information from those text
>       	files, and printing reports based on that information.
> 
> Though it goes on to say that it's "also good for system management 
> tasks", it's clearly an afterthought- shell scripting already had this 
> covered.

Since we are communicating with asterisk via a text interface, we fall
directly into the first part. The agi apps are extracting from that text
information about what has transpired to get us to this point, which
satisfies the 2nd part of the description. The third part of the
description you quote is filled by the messages we pass back to
asterisk. While we may generally think of a report as something humans
read, it is just as easily something machine readable. Only minor
stretching here.


> > 
> > Php is intended to take in user input, chew on it a moment, maybe
> > consult backends, then spew data and die.  
> 
> And what is it about an AGI script that does not meet each and every one 
> of these criteria?

This depends on how you use agi I guess. If you use agi to process user
input from the dialplan and then spit the user back out in some other
section of the dialplan, then I guess it would fit the normal flow of a
php script. On the other hand, agi is able to implement much larger
applications. I wish I had some more time to work on the idea of merging
a MUD application with agi and festival or recorded prompts to give you
a way to navigate around a world with dtmf and be dropped into a meetme
like application at each "room". I think it would be a great toy/add on
to asterisk. Or if you considered a dictation system that requires
larger amounts of interaction with the user to edit a file while it is
being recorded. This all would be accepting data from a user ovr the
entire course of a call instead of getting it early and then dumping the
data and dieing. 

-- 
Steven Critchfield <critch at basesys.com>