Some questions regarding calling Fast AGI from the dial plan. Considering that the server side of the Fast AGI has to be able to a) use threading and b) connect to MySQL, this causes some serious limitations. I'm not a C programmer, so development options are either perl or python. It appears that the perl DBI isn't thread safe, so that rules out Perl. Python's database interfaces are apparently thread safe _to a point_, so that seems like a better idea. I'd prefer to stick with Perl because I am more familar with it, but oh well... Has anyone done this? Was it successful? Did you control the entire dial plan logic from the AGI, or did you just make AGI calls as necessary to look certain things up? What about iterative queries where you had to maintain the state from one call of the AGI to the next? Did you stay in the AGI until control was complete, or did you return control to the Asterisk dial plan after every lookup, where it performed some actions, and then you returned to the AGI.... if this was the way you did it, how did you maintain the database state from one call to the next??? Did you have multiple AGI scripts, broken down by function, or did you have one AGI script that was passed a value that specified it's function, and then you branched into some section of this all-encompassing AGI based on the value passed? Thanks, Doug.
On 1/25/06, Douglas Garstang <dgarstang@oneeighty.com> wrote:> > Some questions regarding calling Fast AGI from the dial plan. > > Considering that the server side of the Fast AGI has to be able to a) use > threading and b) connect to MySQL, this causes some serious limitations. I'm > not a C programmer, so development options are either perl or python.In ref to using perl, You can't connect to the database for each thread? It appears that the perl DBI isn't thread safe, so that rules out Perl.> Python's database interfaces are apparently thread safe _to a point_, so > that seems like a better idea. I'd prefer to stick with Perl because I am > more familar with it, but oh well... > > Has anyone done this? Was it successful? Did you control the entire dial > plan logic from the AGI, or did you just make AGI calls as necessary to look > certain things up? What about iterative queries where you had to maintain > the state from one call of the AGI to the next? Did you stay in the AGI > until control was complete, or did you return control to the Asterisk dial > plan after every lookup, where it performed some actions, and then you > returned to the AGI.... if this was the way you did it, how did you maintain > the database state from one call to the next???Anytime I decide to include AGI into an application, I try to keep most of the code and logic inside the AGI. I have successfully written FastAGI applications in python, and it was a good experience. What state are you speaking of? I don't quite follow. Did you have multiple AGI scripts, broken down by function, or did you have> one AGI script that was passed a value that specified it's function, and > then you branched into some section of this all-encompassing AGI based on > the value passed? > > Thanks, > Doug. > > > > > > > > > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > >-- Sig Lange http://www.signuts.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060125/08631390/attachment.htm
Sure, I can connect to the database for each thread. That doesn't ensure thread safety tho. How can I be sure that there's not state information in DBD/DBI that's being shared (and possibly corrupted) between all perl threads? The Perl DBI docs specifically say it isn't thread safe. What state am I speaking of? A good example is findme/followme. You want a database table that lists for a given extension, a new list of forwarded extensions to try. You want to execute a query, get the forwarded number to try to dial it. If you pass control back to the dialplan, and attempt to dial the number from there, if it fails to answer, then you have to call the AGI script again and execute another query, this time returning the second number. When you execute this second query, how are you going to maintain the state and remember that you have advanced to the next number/row in the table? Obviously if you keep control inside the AGI script, and dial from there, you can maintain the state in the scripting language. If you pass control back to the dial plan, I don't know how you'd do it. I ask because when I posed the question before about whether or not you should execute queries in the AGI and return control to the dialplan, or keep control in the AGI, I was told that it's best to return control to the dial plan and Dial() from there. Doug -----Original Message----- From: Sig Lange [mailto:sig.lange@gmail.com] Sent: Wed 1/25/2006 8:19 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: Subject: Re: [Asterisk-Users] Fast AGI Options. Eeeek! On 1/25/06, Douglas Garstang <dgarstang@oneeighty.com> wrote: Some questions regarding calling Fast AGI from the dial plan. Considering that the server side of the Fast AGI has to be able to a) use threading and b) connect to MySQL, this causes some serious limitations. I'm not a C programmer, so development options are either perl or python. In ref to using perl, You can't connect to the database for each thread? It appears that the perl DBI isn't thread safe, so that rules out Perl. Python's database interfaces are apparently thread safe _to a point_, so that seems like a better idea. I'd prefer to stick with Perl because I am more familar with it, but oh well... Has anyone done this? Was it successful? Did you control the entire dial plan logic from the AGI, or did you just make AGI calls as necessary to look certain things up? What about iterative queries where you had to maintain the state from one call of the AGI to the next? Did you stay in the AGI until control was complete, or did you return control to the Asterisk dial plan after every lookup, where it performed some actions, and then you returned to the AGI.... if this was the way you did it, how did you maintain the database state from one call to the next??? Anytime I decide to include AGI into an application, I try to keep most of the code and logic inside the AGI. I have successfully written FastAGI applications in python, and it was a good experience. What state are you speaking of? I don't quite follow. Did you have multiple AGI scripts, broken down by function, or did you have one AGI script that was passed a value that specified it's function, and then you branched into some section of this all-encompassing AGI based on the value passed? Thanks, Doug. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Sig Lange http://www.signuts.net/