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

[Tim Panton]

On 10 Jun 2007, at 12:38, Tzafrir Cohen wrote:

> On Sun, Jun 10, 2007 at 05:29:08AM -0500, Pari Nannapaneni wrote:
>> 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.
>
> The web server indeed should do minimal processing. But this is not  
> the
> web server doing work. This is a matter of exposing useful information
> available to Asterisk.
>
> There has long been a CLI command 'show dialplan <context>'. So I
> suspect that getting just a specific dialplan context is some very
> relevant information. And probably the more general request of "get
> section foo from onfig file bar".
>
> Ditto for "get me a list of all the section titles from config file
> bar".
>
> Does that add much extra processing on the Asterisk server?

But show dialplan <context> doesn't preserve comments or sequence
in the same way that reading the file does. I don't know if it is an
explicit goal that these things should be preserved if you 'edit' the  
file with
manager actions - but currently it can....

There is also the issue that for show dialplan <context> to do what
we want here, the user has to have done a 'reload' to make the last
set of changes current. The current 'read-a-file' interface doesn't  
require that.
When making a set of related changes you don't necessarily want to  
'commit'
until all the changes are made.

I suppose we need to make an important choice here - is this interface
'file based' or more syntactically aware?

If it is to be file based we should be doing web-dav and not try to  
re-invent the wheel.

If it is to be syntax based, we need to think about mechanisms you  
see in things like
IOS, where you can edit flash, running or memory (but inactive)  
versions of a config.
Also you can get feedback to see if the change you applied is  
syntactically valid.

At the risk of _really_ starting a flame war, the reason the browser  
is slowing down with
lots of data, is that the browser side parser is in javascript. If  
the data format were
in XML we'd have a quick parser for free in every ajax capable  
browser, along with
a sensible syntax for navigating/searching it.

Tim.