[asterisk-users] Any reason to *not* use AEL? (Also, MixMonitor q)
Gavin Henry
gavin.henry at gmail.com
Wed Jun 4 04:45:13 CDT 2008
What about using RealTime LDAP in 1.6? That woudl be much faster than a RDBMS.
2008/6/3 Sherwood McGowan <sherwood.mcgowan at gmail.com>:
> Mindaugas Kezys wrote:
>> Thank you for your opinion.
>>
>> Then my question would follow: how to build human-friendly system which will
>> use GUI and lets user use that system without messing with .conf files?
>>
>> From my experience large and complicate systems can't be effectivelly
>> 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
>>>
>>
>>
>> _______________________________________________
>> -- 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
>>
> There's not really a reason to NOT use extensions.conf, other than it's
> spaghetti code, and not as readable. You CAN write a gui that alters the
> *.ael files, that's how a lot of the GUIs work for extensions.conf, they
> modify the file. Putting your dialplan into a database is needless in
> about 90% of cases I've run across.
>
> --
> Sherwood McGowan
> VoIP / Telecom Solutions
> sherwood.mcgowan at gmail.com
>
>
> _______________________________________________
> -- 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
>
--
http://www.suretecsystems.com/services/openldap/
More information about the asterisk-users
mailing list