Steve Murphy
2006-Dec-08 12:17 UTC
[asterisk-users] Douglas Garstang <dgarstang@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. 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. 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? Tell us what and why, and we may have either condolences or advice for you. What about the \r\n stuff? Where, what? Let me know... I hope you haven't decided, now that you've programmed around it, you don't want it to change! Because Murphy's Law says we'll find the probs with or without your help, and you'll have to deal with the changes at some point in time. I'm willing to fix problems in 1.2; I'll make sure they carry forward into 1.4 and above. murf> > > -----Original Message----- > > From: Steve Murphy [mailto:murf@digium.com] > > Sent: Thursday, December 07, 2006 4:26 PM > > To: asterisk-users@lists.digium.com > > Subject: [asterisk-users] Re: What's up with the Manager > Interface?!?! > > > > > > Doug, Everyone: > > > > I'll make you an offer you (hopefully) can't refuse: > > > > I've been fixing manager bugs here and there, and am > willing > > to take on > > any manager issues out there, for 1.4, and trunk, > especially, so as to > > have things nice and solid for 1.4 before it gets out of > beta. > > > > So, give me some details. I will file the bug, if you don't. > I will > > reproduce(if I can), and debug, and fix 'em. Just tell me > (as > > explicitly as possible, please!) what the problems are-- > > especially you, > > Doug-- where are those inconsistencies, exactly? Richard-- > I'll lab up > > 1.4 and see if I can get the hiccups you mention. > > > > murf-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3239 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20061208/19e7ca9c/smime.bin
Douglas Garstang
2006-Dec-08 13:02 UTC
[asterisk-users] Douglas Garstang <dgarstang@oneeighty.com>
> -----Original Message----- > From: Steve Murphy [mailto:murf@parsetree.com] > Sent: Friday, December 08, 2006 12:14 PM > To: asterisk-users@lists.digium.com > Subject: [asterisk-users] Douglas Garstang <dgarstang@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.