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

Pari Nannapaneni pari at digium.com
Sun Jun 10 01:37:32 CDT 2007


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

Short version:

agreed, lets comeback to this topic when we have some one _actually_
using the gui for 400+ users and complains about performance.


Long Version:

well, I guess, we can live without those _extra_ proposed manager commands in asterisk,

only that in those rare cases of some one using the gui with more than
a couple of 100 users - the gui takes a little more time to load and responds
a little slow - if you use Zimbra you know what i mean.

But IMO - thats the case for any app in which you 
have too much parsing/storing going on in the browser.

Sokol and I had a discussion in the past where we talked about an alternative model for 
the gui where we can load all the config files needed, "only once on login" and use that
cached data in each of the gui pages. But later I realised that model does not suit well
 in a system like Asterisk, where there is a possibility of the config files being constantly changed from many different points in the system.

Examples - users changing their voicemail passwords after admin 
logs into the gui and we still show the old passwords in the gui.
OR - another admin adds a user to the system from a different location
using the same gui and that change will not be reflected in login-1.

And also the added complexity in the code needed for caching/updating all this config data
makes it hard to fix bugs, making it not worth all the effort.

So we never adapted that model and chose to stick with the current way of reading 
the config files again in each and every page of the gui and this is working great
for up to hundreds of users. Lets worry about this when it actually becomes a problem.

thanks,
-Pari



----- Original Message -----
From: "Tzafrir Cohen" <tzafrir.cohen at xorcom.com>
To: asterisk-dev at lists.digium.com
Sent: Saturday, June 9, 2007 11:52:07 PM (GMT-0600) America/Chicago
Subject: Re: [asterisk-dev] Feature Request - new manager commands - 'getcontexts' and 'getcontext'

On Sat, Jun 09, 2007 at 08:27:37PM -0500, Tilghman Lesher wrote:
> 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
> ...

You shouldn't.

The behaviour of Asterisk is not well defined in such a case. This may
easily change from version to version or whatever.

You cound use, e.g. 

[foo]
type=user
...
[foo](+)
host=whatever
...

to add the the existing context. Note that Such context manipulations 
(e.g.: templates) is lost when you write a context from the GUI.

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir
_______________________________________________
--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



More information about the asterisk-dev mailing list