[asterisk-dev] GSoC 2010

[Nir Simionovich]

Hi All,

Well, looks like Steve beat me to the punch here. If according to 
Russel's design pattern REST and
other "external achievable" tools have no place in the dialplan, thus, 
the following don't have place in the
dialplan either: MYSQL, CURL, ODBC and some others (can't recall all at 
this time).

I understand where the decision is coming from, and judging it purely 
from a design point of view, it
makes sense. However, I do believe that these have a place, as I've seen 
many people use these. Why
not add it under the asterisk-addons project, instead of being a core 
function. In this respect, it's not
part of the main Asterisk core, and who wants to use it can still get it 
from the addons package?

Nir S

Steve Edwards wrote:
> On Tue, 2 Feb 2010, Chris Tooley wrote:
>
>> On Tue, Feb 2, 2010 at 5:46 PM, Mat Murdock
>> <mmurdock at kimballequipment.com> wrote:
>>> On 2/1/2010 4:09 PM, Russell Bryant wrote:
>>>> On 02/01/2010 05:05 PM, Chris Tooley wrote:
>>>>
>>>>> I have to say I completely agree. There are some things for which the
>>>>> Dialplan is great, and then there are things that really should be
>>>>> done in an AGI or EIVR application. The Dialplan should not be
>>>>> complicated to the point of being unusable by trying to include every
>>>>> possible feature and concept. Especially since, at some point, it
>>>>> becomes maintaining a programming language of it's own and is outside
>>>>> the scope of the project.
>>>>>
>>>> We are basically going up against design decisions made for Asterisk
>>>> ages ago. �The dialplan already is a programming language to some
>>>> extent. �I think our job today is to resist feature creep in the
>>>> "language" and only provide what is necessary. �I would much rather 
>>>> put
>>>> effort into making it easier to take advantage of the work that the
>>>> communities that actually specialize in making a programming language
>>>> have already done.
>>>>
>>>>
>>>
>>> I understand where you are coming from, but wouldn't such a function
>>> take core of one of the main reasons people jump use agi to begin with?
>>> It is my understanding that it is faster and less resource intensive to
>>> stay in the dialplan vs going to agi.
>>>
>> With FastAGI I don't think this is an appreciable difference, and
>> depending on the implementation FastAGI or ExternalIVR over a socket
>> should be just as fast.
>
> If "plain" AGIs are written in a compiled language the execution speed 
> should be similar to "native" Asterisk code and any modern processor 
> can handle XXX process creations per seconds.
>
> I would be OK with deprecating some current daiplan features such as 
> database access.
>