What about using RealTime LDAP in 1.6? That woudl be much faster than a RDBMS.
2008/6/3 Sherwood McGowan <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] [mailto:asterisk-users- >>> [EMAIL PROTECTED] 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:* [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] *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 <[EMAIL PROTECTED] >>>>> <mailto:[EMAIL PROTECTED]>> 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 > [EMAIL PROTECTED] > > > _______________________________________________ > -- 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/ _______________________________________________ -- 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
