[Asterisk-Dev] Manager XML

[Ben Miller]

I would agree that it seems that people are trying to adapt the manager
interface into something that it was not designed for or that Mark
doesn't envision it being used for.  However, I too have been bitten by
the bug of trying to use the manger interface output in an application
and had it change or be inconsistent and break stuff.

If there is going to be discussion about a new interface module to
interact for control/subscription; one feature that I had tried to code
up a long time ago, (never to my satisfaction so I never submitted it)
is a user level access control to specific channels/features via this
interface.

What this means is that an end user could listen to or control features
of their channels only, via this interface, offering application level
security rather than interface level security or no security at all for
applications such as TAPI or operator panels or other GUI things.  What
I mean by "their channels" is the channel their phone is on and any
channel it is bridged to at the time.  

All the features and attributes of this interface could be encoded in
whatever makes the most sense to the module developer, binary, xml, pig
latin, whatever.

Just thought I would throw my $0.02 in when this topic strayed to
something I had been thinking about for a while anyway.

Thanks,
Ben


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Adam
Goryachev
Sent: Wednesday, March 02, 2005 10:06 PM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] Manager XML

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

_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev