[asterisk-dev] GSoC 2010

[Olle E. Johansson]

Even though Russell has final word, I hope that he still listens to the dev community in large before carving these decisions in stone. I think he was just making his personal feelings known, and is open for discussion. Start developing and prove that it's a useful addition. Use the asterisk-forge, but take care to maintain license cleanless if you want to integrate it into Asterisk at a later point.

Go where no Asterisk developer has gone before. Invent, impress and convince us all.

/O

PS. And we have a realtime HTTP driver (curl)...

3 feb 2010 kl. 14.58 skrev 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.
>> 
> 
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden