[Asterisk-Dev] Manager XML

[Adam Goryachev]

On Wed, 2005-03-02 at 19:02 -0600, Brian West wrote:
> I recommended that already and he pretty much said NO.  He said he was 
> open to new ideas... except when it comes to this one :P
> 

I don't know as much as I wish I did about the asterisk source/structure
etc, but occasionally I might hack some of the source, and one of my
patches even made it into CVS. Further, I don't really know very much at
all about XML, yet I still seem to think that *this* application of XML
isn't such a bad idea...

IMHO, there are some things that the manager interface is lacking, and
there are some things that it does very well. Perhaps it is time to
divide and conquer, or, in other words, take each problem the manager
interface solves now, and solve them individually, not necessarily all
with the same method.

ie, problem one is listening to events from asterisk so that we know
what is happening. This (IMHO) is relatively well done at the moment,
with colon separated tag:value pairs. Perhaps some work could be done to
include some sort of eventid or something to better track them, but
overall, it is a good solution. We will receive all of one event before
the next one, there is little processing overhead to send the events,
and it is easy to receive/process them in turn. Also, we can send all of
the information that anyone seems to ask for (anyone want more??)

Second problem is telling asterisk what to do, and finding out the
results of those instructions. This includes pulling status reports like
queue status, or sip peers, etc...
Currently, we ask for what we want in tag:value pairs, and are returned
what we asked for in tag:value pairs. Sometimes this result is returned
mixed in with other events that are happening, and overall, seems like
often the data we request isn't returned in an ideal format....

So, perhaps we need to simplify the manager interface, and return it
back to a pure event broadcast system, and add another interface which
we can send/receive request/responses in. As far as the format that we
would submit the requests in, and the format to receive the response in,
I don't really want to comment on too much. tag:value seems very
flexible/extensible, and seems to work quite well for every case I've
seen. However, I am sure there are cases where XML would be ... more
convenient... but I'm not convinced we couldn't still do all this in
tag:value format....

There are probably other 'parts' that could be split off, and the above
may not be the 'best' method to solve the parts I've mentioned, but I
think that concentrating on each part individually, and solving each
part in the best way possible first, and *then* combining the parts if
possible.

BTW, I do think a helpful feature would be the ability to say something
like "I only want events that relate to this channel/peer/etc" then you
will *only* see events that 'interest' you.

Regards,
Adam

-- 
 -- 
Adam Goryachev
Website Managers
Ph:  +61 2 8304 0000                        adam at websitemanagers.com.au
Fax: +61 2 9345 4396                        www.websitemanagers.com.au