|Summary:||ASTERISK-03816: [patch] New CLI command - show cdrdrivers|
|Reporter:||Olle Johansson (oej)||Labels:|
|Date Opened:||2005-03-31 04:25:36.000-0600||Date Closed:||2011-06-07 14:05:26|
|Environment:||Attachments:||( 0) cdrdrivers.txt|
|Description:||Lists loaded CDR drivers and their description|
Disclaimer on file
|Comments:||By: Olle Johansson (oej) 2005-03-31 04:33:31.000-0600|
Would be good to have an API into each channel driver to check it's status, whether it's active or not (and maybe the # of saved CDR records).
By: Kevin P. Fleming (kpfleming) 2005-03-31 11:10:57.000-0600
Can we do something like 'cdr show drivers' or 'cdr show backends' instead of adding more stuff onto 'show'? I know Mark likes being able to type show<TAB> and get an insanely long list of options, but I think most people know that if they want CDR related stuff, they can type cdr<TAB> to find what they need.
By: Olle Johansson (oej) 2005-03-31 13:13:01.000-0600
I fully agree with you, hate all those "show" commands, but Mark has been refusing me to change them so I keep adding :-)
Check what's his wish, and tell him that we two agree to change this.
What's your thought on adding an API callback, so that we can check the status. Like knowing that cdr_mysql isn't active even if it's loaded...
By: Kevin P. Fleming (kpfleming) 2005-03-31 13:27:14.000-0600
I'm not sure how valuable that 'active' status would be to have... people who really care about that just won't load the modules they don't want to use, right?
By: Olle Johansson (oej) 2005-03-31 14:49:51.000-0600
The problem is when you want a module to be active, it loads but fails to connect to the db - then it's inactive... I would like to be able to show that, so that people can dig into the log files and find out why it's not active.
By: Olle Johansson (oej) 2005-03-31 14:50:15.000-0600
Anyway, so what about the command syntax? ;-)
By: Kevin P. Fleming (kpfleming) 2005-03-31 15:39:35.000-0600
I'm waiting for Mark to have 30 seconds in a row to ask him about it :)
By: Kevin P. Fleming (kpfleming) 2005-03-31 22:03:11.000-0600
We have a final answer: go ahead with "cdr show drivers" or similar.
By: Tilghman Lesher (tilghman) 2005-03-31 23:40:55.000-0600
I must be missing something. Why not just type 'show modules like cdr_'?
By: Kevin P. Fleming (kpfleming) 2005-04-01 10:30:35.000-0600
He wants the 'cdr show drivers' command to be able to actually show information about them as well (active/inactive, etc.).
By: Tilghman Lesher (tilghman) 2005-04-01 11:00:59.000-0600
'show modules like cdr_' already shows usage.
By: Olle Johansson (oej) 2005-04-01 13:34:42.000-0600
Corydon: The cdr_mysql loads and is shown as loaded, but I can't find out if it's active or not. Usage does not show if it gave up since it had the wrong password or other statuses - lost contact with database in odbc.
By: Tilghman Lesher (tilghman) 2005-04-01 13:57:59.000-0600
oej: I fail to see how the patch uploaded does any of those things.
By: Kevin P. Fleming (kpfleming) 2005-04-01 14:06:15.000-0600
That's correct, at the moment this patch does not provide any additional information that 'show modules' doesn't display.
By: Olle Johansson (oej) 2005-04-01 15:34:35.000-0600
No, corydon, this patch is a starting point... Sometimes you have to take it in steps to get anywhere.
By: Tilghman Lesher (tilghman) 2005-04-01 15:42:18.000-0600
My point, though, is that at this juncture, it's premature to upload a patch, as your patch doesn't do anything close to what you want to do. This bug needs to be a [request] or [discuss], not [patch], since the patch is not, by your own admission, ready for inclusion.
By: Kevin P. Fleming (kpfleming) 2005-04-01 15:42:55.000-0600
I think I'd rather see the patch contain that behavior, then, rather than adding a command that doesn't currently provide any new functionality.
By: Olle Johansson (oej) 2005-04-01 16:02:08.000-0600
I consider it much more userfriendly as it is, than to list modules. Even if it is possible to list modules by "cdr_*" most users will not find that. If we have a command, that will make users find it and use it.
I've seen a demand for these kind of commands while doing trainings in Asterisk. Not everyone becomes a guru and need assistance in the application. It certainly will not hurt the application to add the command as it is.
I consider the patch ready for CVS.
With your logic, we have to remove the "iax reload" command that was added, since you can "reload chan_iax2.so"... I think "iax/sip reload" is much, much more userfriendly and makes more sense, even if you can do it the other way. Forcing users to learn and remember module names is not very friendly.
By: Olle Johansson (oej) 2005-04-01 16:02:32.000-0600
...ready for cvs when I change the CLI command, that is...
By: Kevin P. Fleming (kpfleming) 2005-04-01 16:17:53.000-0600
I don't disagree with that, in fact we spent quite some time convincing Mark that 'iax2 reload' was a good idea, even though it does not provide any new functionality.
However, since there are no existing commands starting with 'cdr', adding this one doesn't play into people's existing habits, they don't have any yet :-) Given that, I've no doubt that Mark wouldn't want this committed until it actually provided new functionality.
By: Tilghman Lesher (tilghman) 2005-04-01 16:21:34.000-0600
On the contrary, the "iax2 reload" and "sip reload" commands predate the functionality of "reload chan_iax2.so" and "reload chan_sip.so", so those two commands stay for legacy reasons (because people already are accustomed to them). Compare this to your command, where there is an acceptable way to do what you want to do already, and it's merely a matter of training users to use that command (an activity that you admit to being part of already!).
By: Tilghman Lesher (tilghman) 2005-04-01 16:31:20.000-0600
Pardon, only the "sip reload" predates "reload chan_sip.so"
By: Olle Johansson (oej) 2005-04-03 15:23:28
--- Will re-open when I have time to finish the CDR status function (or if someone else is willing to code that missing part ---