<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 8, 2015 at 10:37 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1) Not all of the data you may want to retrieve may be readily<br>
available. Granted, right now, I don't think that's the case, but<br>
there's certainly more flexibility if you have access to Asterisk's C<br>
APIs.<br></blockquote><div><br></div><div>If the time comes when a piece of information is needed not exposed through AMI, then it probably should be exposed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) There's no real way to guarantee that someone will run a daemon<br>
next to Asterisk, or that said daemon won't have some other<br>
interaction that we won't expect.</blockquote><div><br></div><div>We agree here, there's no guarantees, but with a separate daemon you can kill it without risking your production traffic.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The only way I can think of to<br>
reasonably introduce such a daemon is to make it part of the Asterisk<br>
'install' target, and/or add it to packages. I'm not sure if having a<br>
separate daemon spin up suddenly on someone's system, with no<br>
warnings, would be much better.<br></blockquote><div><br></div><div>Yeah that's what I had in mind (part of the install target). It would also make it more obvious for users that something is gathering stats, easier to 'analyze' what exactly is doing (e.g strace it)</div><div>and being in a scripting language would make it easier for sys admins to contribute bugs and fixes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That being said, I do think there's a few small benefits to making<br>
this part of Asterisk:<br>
1) We can give a visual warning that it is enabled. That's not as easy<br>
to do via an external process.<br></blockquote><div><br></div><div>I don't agree here. Adding a warning should be trivial. Issuing a 'log' action when the external process connects. I can't recall top off my head</div><div>if this exists already (the log action through AMI), but if not, it's trivial to call ast_log() with a message received from an external process as an AMI action.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Disabling it is done in a manner that is similar to other Asterisk<br>
modules - don't build it in menuselect, or disable it in a .conf file.<br></blockquote><div><br></div><div>This is something I agree with. There's more 'friction' since it's different, and it would be the first time, I think, an external daemon is introduced. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Less important, it would have access to the C APIs in Asterisk.<br></blockquote><div><br></div><div>I see this as a non-issue really. Statistics such as these are useful for other purposes (graphs, etc) so having them available</div><div>through AMI and/or command line for Asterisk users is something good, so they should not be only available through the C API anyways. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Your point is a good one though. No one wants the statistics module to<br>
have a negative impact on their system. To that affect, there's a few<br>
ways the proposal on the wiki minimizes risk:<br>
1) It's relatively simple, and doesn't try to get a bunch of<br>
information out of a lot of modules that may or may not be there. To<br>
whit, all of the APIs needed for the information are in the core, and<br>
have a reasonably minimal impact on the run-time aspects of Asterisk:<br>
  - ast_get_version/ast_get_version_num: version.h<br>
  - ast_active_calls/ast_processed_calls: pbx.h<br>
  - ast_startuptime/ast_lastreloadtime: global constants in options.h<br>
  - ast_update_module_list: module.h<br>
2) The project plans outlines tests that should be created for the<br>
module. That includes standing up a version of the REST API in the<br>
testsuite, and providing both nominial and off-nominal tests.<br></blockquote><div><br></div><div>That's fair. If this is the direction you choose to go, the simpler the better, so I also agree queueing or clever re-trying schemas are better avoided.</div><div><br></div><div>Cheers,</div><div><br></div><div>Moy</div></div></div></div>