[Asterisk-Dev] C AGI clarification

[Steven Critchfield]

On Thu, 2005-02-10 at 17:24 -0800, taintedham-mailinglists at yahoo.com
wrote:
> Ok, there seems to be a little confusion.  I'm not
> saying you can't make an AGI in C.  You can, in fact
> you can make an AGI in anything.
> 
> However, AGI is a protocol that defines the
> communication between an app and the res_agi in
> asterisk.  As such, it requires parsing of textual
> strings and requires forking, etc.
> 
> Looking further into the res_agi, it looks like I
> could simply separate the functions res_agi uses when
> parsing AGI output.
> 
> The idea isn't to create an AGI.  The idea is to
> create an app module that uses the same api as an AGI.
>  The benefits would be that it executes faster (loaded
> in mem, no need to parse, etc), is programmed similar
> to the AGI (so hopefully since AGI is pretty stable,
> so will the functions that AGI rely on), and the C
> code could drop down to a lower level than possible in
> AGI.
> 
> Basically, I propose we break res_agi into C library
> for use in simple apps.... and a res_agi module (as it
> is now) which executes external AGI programs using the
> C lib.  This would give C programmers a standard API
> interface to the asterisk core.

I'll throw out that you seem to be barking up a strange tree. Have you
actually looked through the AGI code? Last time I had to deal with it,
it looked pretty simple to deal with the API directly. 

BTW, other than the stableness that AGI provides with respect to the
API, AGI also affords you the seperate address space to make sure any
coding error you make doesn't take the PBX down with it. 

As for speed of execution, you can't play twitch games where the
controls take 40ms minimum to register and is likely 55-80ms. Most
commands in AGI are no more than 50-80 chars and a response is about 30
or so chars. If asterisk signals the DTMF to the AGI at 45ms, it is
highly likely your app has already processed the string and send it's
own string with a few ms extra in the gap there to do other decision
making before the user can even hear anything.

If you need faster than that, you need to get off of the phone lines and
start looking at direct data links.
-- 
Steven Critchfield <critch at basesys.com>