managed without Realtime and I see no way how to put AEL into DB. Maybe it's
possible?
We are storing "exact-match" info into DB and all _X., etc stuff we
have in
extensions.conf. So no speed issues with large systems.
Also: Any reason to "not" use extensions.conf?
What AEL can do better then extensions.conf?
Many people still use vi. Because it can do everything what they want. Same
here with extensions.conf.
Regards,
Mindaugas Kezys
http://www.kolmisoft.com
> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] On Behalf Of Steve Murphy
> Sent: Tuesday, June 03, 2008 9:02 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] Any reason to *not* use AEL? (Also,
> MixMonitor q)
>
> On Tue, 2008-06-03 at 09:33 -0500, Sherwood McGowan wrote:
> > Mindaugas Kezys wrote:
> > >
> > > Does Asterisk Realtime support AEL?
> > >
> > >
> > >
> > > Regards,
> > >
> > > Mindaugas Kezys
> > >
> > > http://www.kolmisoft.com
> > >
> > >
> > >
> > > *From:* asterisk-users-bounces at lists.digium.com
> > > [mailto:asterisk-users-bounces at lists.digium.com] *On Behalf Of
> > > *Gonzalo Servat
> > > *Sent:* Tuesday, June 03, 2008 5:07 PM
> > > *To:* Asterisk Users Mailing List - Non-Commercial Discussion
> > > *Subject:* Re: [asterisk-users] Any reason to *not* use AEL?
(Also,
> > > MixMonitor q)
> > >
> > >
> > >
> > > On Tue, Jun 3, 2008 at 10:41 AM, Eric Wieling <eric at
fnords.org
> > > <mailto:eric at fnords.org>> wrote:
> > >
> > > AEL in 1.4 was the first version of AEL that most people
> consider
> > > "stable". Since not many people uses AEL, you
won't get nearly
> as
> > > much
> > > (if any) community support compared to if you are using the
> > > non-AEL syntax.
> > >
> > >
> > > Really? Why would anyone want to write a dialplan using the old
> > > extensions.conf syntax? That sort of syntax personally drove me
> nuts
> > > (and real messy). I've got my entire dialplan on AEL (using
> Asterisk
> > > 1.6.0).
> > >
> > >
> > > -
>
> > Not sure what you mean, but if you mean realtime dialplan, then no,
> > you can't use AEL for that. However, we might wish to see if Murf
> > knows if this can be done.
> >
>
> extensions.conf is like assembler; it's a very strict, line per
> instruction format, 4 fields per line, that is able to be read in by
> normal config file parsers. It is in turn compiled into the internal
> asterisk data structures.
>
> AEL is more free form. Storing the dial plan in AEL format in a db
> would be pretty useless. However, the extensions.conf isn't so bad in a
> db, as it still has the 4 columns, row per instruction sort of format.
>
> But in general, I have to ask, as a programmer, if it's really, really
> a good idea to store code in a db. The dialplan is a mixture of both
> dialplan code and data, in the form of extensions.
>
> But storing dialplan "code", as in a sequence of application
calls, is
> a slow way to execute your dialplan code.
>
> And storing patterned extensions (extensions starting with _, like
> _10XXXXXXXXX or whatever), is a really slow way to match pattern
> extensions. My advise to everyone is this: Realtime is great, but don't
> store extension patterns in there, and don't store your dialplan code
> in there, if you can help it. It'd be much better to use your db to
> store 'exact' extension data. Trying to find the best pattern match
via
> realtime is excruciatingly slow, as it calls up every extension in the
> db for that context, and then decides on the best match. DB's do a
> great job at storing large numbers of uniquely keyed data that you can
> find via exact matches. So, use a general exten patten in your
> dialplan, and then do a DB() lookup from there.
>
> If you find a bug in your dialplan code, you've got to change it in two
> places, in the realtime db, and you'd best have it in your original
> source as well, in case you need to reload/recover your db or whatever.
> A DB is a lousy source-code control system. Use cvs or subversion or
> git or something to store your dialplan code instead. That way, you can
> back out change sets, etc, and track your changes in a much more
> practical way.
>
> Just my two cents.
>
> murf
>
> --
> Steve Murphy
> Software Developer
> Digium
