[Asterisk-Dev] realtime extensions db friendliness

[Brian West]

Its not just realtime .. every single switch from iax to dundi does 
this.

/b

On Apr 7, 2005, at 9:35 PM, Terry Wilson wrote:

> 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
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev