[asterisk-dev] Feature Request - new manager commands - 'getcontexts' and 'getcontext'

[Pari Nannapaneni]

Tim wrote:
> Wouldn't it be better to split the file up into smaller files each of  
> which can be up/down loaded
> with the existing mechanism ? All Pari then needs to do is to have a  
> extensions.conf that 'includes' all the little files?
>

What we have now is working fine, except there are few times where we are forced to read
an entire file on the client side - even if we are looking for just one context in it. So i requested
having an option that can be used to retrieve just the particular context from a config file. 

The question that was raised is - can we keep adding manager actions like these to the web server, 
because the objective was to have a really thin webserver that does not steal any significant 
cpu cycles and to leave all the file parsing to the clients.

-pari


----- Original Message -----
From: "Tim Panton" <tim at mexuar.com>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Sunday, June 10, 2007 3:25:51 AM (GMT-0600) America/Chicago
Subject: Re: [asterisk-dev] Feature Request - new manager commands - 'getcontexts' and 'getcontext'


On 9 Jun 2007, at 23:59, Caio Begotti wrote:

> On 09/06/2007, at 16:57, Tilghman Lesher wrote:
>> Wouldn't adding these commands defeat the intent of the http  
>> server in
>> Asterisk?  The intent, as I understand it, is to be lightweight,  
>> to shift all
>> of the complexity of the configuration into the browser, so the  
>> Asterisk
>> process isn't spending time doing string processing for the  
>> manager interface
>> (and thus properly spends its time on call processing).
>
> I understand that adding new manager commands with *almost* the  
> same behavior is not good at all, but considering that web  
> applications are not that smart and fast when doing big parsings  
> maybe it would help Pari in his task.
>
> I compare that with a very huge file and a magic "sed" command that  
> does the trick but is awful and slow. However, it still seems to be  
> a design issue: adding new manager events once in a week seems to  
> be wrong, I agree.
>
> If the problem is performance here, as Pari seems to state so, then  
> perhaps it's really necessary to put it inside the manager code to  
> make it fast and specialized instead asking Asterisk for the whole  
> extensions.conf with hundreads of contexts and big contents (yeah,  
> ok) then parsing it all. Anyway, as you said, it isn't necessarly  
> that intensive for a C app :-)

Wouldn't it be better to split the file up into smaller files each of  
which can be up/down loaded
with the existing mechanism ? All Pari then needs to do is to have a  
extensions.conf that
'includes' all the little files?

Tim.


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev