Re: [Asterisk-Users] Fast AGI Options. Eeeek!

2006-01-26 Thread Simone Cittadini

Sig Lange ha scritto:



 I have successfully written FastAGI applications in python, and it 
was a good experience.


Do you have some template code you can share ? or references to point us 
to ?

___
--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


[Asterisk-Users] Fast AGI Options. Eeeek!

2006-01-25 Thread Douglas Garstang
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.
 
 
 
 
 
 
 
 
___
--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


Re: [Asterisk-Users] Fast AGI Options. Eeeek!

2006-01-25 Thread Sig Lange
On 1/25/06, Douglas Garstang [EMAIL PROTECTED] 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 Langehttp://www.signuts.net/
___
--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


Re: [Asterisk-Users] Fast AGI Options. Eeeek!

2006-01-25 Thread Script Head
On 1/25/06, Sig Lange [EMAIL PROTECTED] wrote:
On 1/25/06, Douglas Garstang [EMAIL PROTECTED] 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? you would have to connect to the database from each thread, i strongly suggest you use something like sqlproxy (for mysql) or pgpool for postgres and actually have a thread close the connection once it's done, otherwise you're going to have a very large number of idle connections to the database.

___
--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


RE: [Asterisk-Users] Fast AGI Options. Eeeek!

2006-01-25 Thread Douglas Garstang
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:[EMAIL PROTECTED] 
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 [EMAIL PROTECTED] 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/ 

___
--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