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

[Tilghman Lesher]

On Saturday 09 June 2007, 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.

Web applications are plenty smart, as is Pari.  He was asking for an
architectural opinion about the addition of new commands.

> 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 :-)

The problem is absolutely performance, and the problem is that Asterisk
should be doing other things, especially on the platform for which the GUI
was developed, which is not a multi-GHz CPU.  Again, we need to reserve
CPU to call processing, and let the multi-GHz CPU (i.e. in the browser)
handle the more complicated tasks of parsing the files.

Pari wrote:
> getcontext(*new) - returns the content of a particular context
>    like: action=getcontext&filename=somefile.conf&context=context-1  should
> return only context-1 [context-1]
>        exten = s,1,NoOp(line1)
>        exten = s,2,.....

One additional problem:  what happens if you have a file, such as iax.conf,
for which contexts may repeat?  e.g.
[foo]
type=user
...
[foo]
type=peer
...

-- 
Tilghman