[Asterisk-Dev] RE: Asterisk license (fwd)

[Ben Lear]

>
>-----Original Message-----
>From: asterisk-dev-admin at lists.digium.com 
>[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of 
>Steven Critchfield
>Sent: Thursday, 2 October 2003 11:58 AM
>To: asterisk-dev at lists.digium.com
>
>On Wed, 2003-10-01 at 19:19, John Todd wrote:
>> At 9:56 AM +1000 10/2/03, Ben Lear wrote:
>> >[snip]
>> >Let the flaming begin :D
>> >
>> >Ben.
>> >
>> >PS: I would consider donating my ODBC wrapper code/time to 
>the "Lets 
>> >get this database crap sorted once and for all cause" if enuff 
>> >interest is shown.
>> >
>> 
>> Yes, I would have quite an interest in making a generic toolkit 
>> interface for Asterisk to talk with databases.  Currently, I 
>am locked 
>> into writing hacks to get to database information, or 
>building config 
>> files with similar hacks.  Even just a few simple routines 
>to replace 
>> "DBGet" and "DBPut" with something that talks to an external system 
>> would be welcome; no need to replace the whole system all at one 
>> time...
>
>Not that this solves the other part of the problem, but did 
>you look into PGSQL commands in asterisk? It allows you full 
>database access from the extension logic.
>
>Now for the interesting part. I mentioned this once before, 
>but shouldn't we make a SQL resource and then use it to make 
>the connections to the database? 
>
>I would prefer this solution especially if ODBC was to be used 
>since you could prioritize your SQL commands and those with 
>low priority could go to the lower end of the list in the 
>event of database overrun. Take for instance CDR events as 
>having lower priority as they are written at the completion of 
>the call and no one is being impacted. Then say your voicemail 
>app could run medium to high priority since you would have a 
>user being impacted. Also with all the  queries going through 
>a single point, you only have less chances of a connection 
>timing out and you don't have to worry about how many users 
>you appear to be to any proprietary DB back end. Also later on 
>adding SQL support to a app is not much more than issuing the 
>correct res_sql_ commands instead of linking in anything else.
>
>What is anyone elses thought about going the resource route?

I think the reasource idea fits into the ODBC/Database Toolkit
concept perfectly. The whole point is to remove the need to worry
about how blah blah database handles such and such. You just call
res_sql_prepareqry().....res_sql_execqry() etc. *What* gets put in
the database is a whole other issue and not really within the scope
of what I'm trying to flesh out. As far as performance/priority
requirements go there are a number of ways to get around the performance
issues(Connection Queues/Pools etc) though these can be worked on
*at some later time*, the immediate need is to get something implimented
with an interface that remains fairly stable. As ODBC/SQL is a mature
and well known standard, coming up with an Asterisk SQL reasource API
should be a straight forward execercise. I'm going to do a little more
code crawling to see how this might all come together.

Keep the ideas comming :)

Cheers,

Ben.