[asterisk-dev] Feature Request - new manager commands -
'getcontexts' and 'getcontext'
pari at digium.com
Sun Jun 10 05:29:08 CDT 2007
> 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.
----- 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
>> 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
'includes' all the little files?
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
More information about the asterisk-dev