[asterisk-users] Douglas Garstang <dgarstang@oneeighty.com>

[Douglas Garstang]

> -----Original Message-----
> From: Steve Murphy [mailto:murf at parsetree.com]
> Sent: Friday, December 08, 2006 12:14 PM
> To: asterisk-users at lists.digium.com
> Subject: [asterisk-users] Douglas Garstang <dgarstang at oneeighty.com>
> 
> 
> On Fri, 2006-12-08 at 04:26 -0700, Douglas Garstang wrote:
> >         Hi Steve.
> >         
> >         Thanks, but unfortunately, I can't be involved in 
> that. We are
> >         running Asterisk in a production environment and we're using
> >         1.2, not 1.4. I don't have the resources to work with 1.4.
> >         Last time I filed a bug against 1.2 I got told off.
> >         
> >         Here's an example of that cruddy output. 
> >         
> >         hestia*CLI> dundi show peer 00:0e:0c:a1:92:4d
> >         Peer:    00:0e:0c:a1:92:4d
> >         Model:   Symmetric
> >         Host:    xxx.187.142.203
> >         Dynamic: no
> >         KeyPend: no
> >         Reg:     No
> >         In Key:  dundikey
> >         Out Key: dundikey
> >         Include logic:
> >         -- include all
> >         Query logic:
> >         -- permit all
> >         hestia*CLI> 
> >         
> >         The delimiter should not be the colon, as the data may also
> >         contain a colon (in this case the MAC address). 
> That makes it
> >         really difficult to split the data into fields. Also, the
> >         apparent key:value rule gets broken when you get down to the
> >         Include Logic line. The '--include all' should be 
> on the same
> >         line!
> >         
> >         Just about every single Asterisk command has 
> screwed up output
> >         like this. Fixing all this would be a LOT of work.
> >         
> >         Doug.
> 
> Doug--
> 
> I'm confused now. You had some references to manager related 
> output, and
> now, you are complaining that CLI output isn't easily machine 
> readable.
> CLI responses were always intended to be read by humans, and 
> the format
> above is tailored to be read by humans. I have no intention 
> in modifying
> CLI responses. They look fine. If you are going to analyze
> human-readable output, you are getting into the realm of data mining,
> and yes, it'll be hard to parse. Add to that, the fact that 
> there is no
> guarantee that the responses won't change from release to 
> release to fit
> with changing conditions, times, and needs, and you have a real
> challenge ahead of you. 

Steve, the cli output I showed IS from the Manager Interface, accessed via syntax 'Action: Command:\nCommand foo\n\n' syntax.
Given that the number of native commands available to the Manager is small, this means that MOST commands must be accessed via the 'Action: Command\nCommand: command\n\n' syntax, and it therefore means that CLI inconsistencies plague most operations. Why haven't ALL the CLI commands been added to the Asterisk manager interface?

> Am I to assume that you playing with CLI output, because you need info
> you can't get via the manager interface? We would need to (in the case
> of your example) extend the dundi module to provide manager 
> actions that
> would provide the info you need. If this is the case, then it 
> would help
> to know which juicy tidbits you need, so we can do it.

How about extending all commands so that everything available via the CLI is available via the AMI? Otherwise, what's the point in having a manager interface?

> If this isn't the case, then it might be better to interact with
> asterisk at a different level... reading the config files, writing an
> app, something...! Funcs are another way to access otherwise embedded
> information, as your example indicates. Maybe we need to create a
> function to access the fields you need?  

Oh right... C programming.

> 
> Tell us what and why, and we may have either condolences or advice for
> you. 

We need to access the complete range of functions available via the CLI, via the manager interface.