[Asterisk-Dev] realtime extensions db friendliness

[Terry Wilson]

On Apr 7, 2005 8:15 PM, Brian West <brian.west at mac.com> wrote:
> Actually its not realtime problem.  The switch API does this ... thats
> all that needs to be fixed.  I have bitched about this... we have
> brought this up to mark before and nobody has even come up with a fix.


Maybe something like:

extensions.conf
[general]
;if you primarily use Realtime switches as opposed to IAX based switches
;you might want to set this to no.  Default is yes.
switchparanoia = no

Details left for homework.  :-)

Seriously though, there are worse problems than this with using the
switch infrastructure for RealTime extensions.  If you are dynamically
adding/creating users who require their own context (overlapping
extensions with other people on the box or something else) with a web
front-end and want to get away from having to do reloads , you still
can't use Realtime as it sits because you have to have the context
exist before you can put a switch statement in it.  So you have to
either 1)modify the extensions.conf file to include the context and
switch => Realtime statement and reload 2)use the static db config
engine to add the context and switch => Realtime statement and reload
or 3) forget using realtime at all and use res_perl.

Aside from the fact that this keeps me from using Realtime in real
time, is the database query issue.  If it would be accepted to do
realtime "Some Other(Better) Way(tm)" and get it into CVS, then maybe
someone could work on it.  If it would never be accepted, then of
course no one should waste their time.

It seems to me that from the db side, you should pull ALL priorities
for an extension with a single query.  Generally if step 3 changes in
the middle of your call, it is going to screw something up.  Better to
have a more atomic solution so that each call has a better chance of
having a coherent list of steps.  If you don't find the specific
extension, query again for the patterns (although you could probably
do one query including the patterns with a handy ORDER BY clause that
allowed you hit the ones first that weren't pattern matched).  Query
again for hangup/timeout/invalid (or pull them with the first query
again) and your are done.  It seems that the fewer queries the better
the overall performance.

Supporting caller-id fields would be handy/not particularly difficult
as would handling includes (though they are less of a concern if you
are using automated scripts to store your dialplan info).

Anyway, just my $0.02.

Terry