For me, the "best" is the curl function, along with res_config_curl. Best of all worlds - pass a web query to *whatever* backend system you want to implement. No messy ODBC drivers.
It's really, really good stuff ;) Julian. Jared Smith wrote: > On Sun, 2008-11-23 at 00:47 -0500, Al Baker wrote: > >> Quote " >> The preferred method is to use func_odbc, which takes SQL queries and >> builds custom dialplan functions from them. I've used it quite a bit, >> >> and am very happy with it." >> >> How can you be VERY HappY with something that allows ONLY single statemts >> of SQL >> > > My intention here is not to start a flamewar over which one is *best*, > or worse to start arguing about who is right instead of what is right. > You're absolutely correct in your assertion that func_odbc doesn't > currently support multi-statement or transactional statements, which is > obviously a limitation to some people. As I pointed out in my other > response to this thread this morning, Tilghman Lesher is working on > that. Feel free to look at his odbc_tx_support branch on the web at > http://svn.digium.com/view/asterisk/team/tilghman/odbc_tx_support/, or > to check it out via Subversion at > http://svn.digium.com/svn/asterisk/team/tilghman/odbc_tx_support/ > > One other way of working around the problem is to use stored procedures > in the database. > > That being said, I guess I'll articulate my own personal reasons for > preferring func_odbc, and leave it at that. > > 1) I like that my dialplan isn't tied to one particular database. I've > done a *lot* of database work in my short career, including being a > sysadmin for one of the largest MySQL database installations in the > world. I *love* the fact that the ODBC abstraction layer means I can > easily change my backend database from MySQL to PostgreSQL (or Oracle or > SQL Server, heaven forbid!) at the drop of a hat. I realize that might > not be a big attraction for some, but for me it's a big plus. > > 2) I don't like the licensing mess associated with linking MySQL > directly to Asterisk. I'm sure there are a few people on the list that > really enjoy the convoluted logic of tip-toeing the licensing minefield > of linking (dual-licensed) Asterisk with (dial-licensed) MySQL, but I > prefer to avoid the minefield altogether and use ODBC. > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
