<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How often were you envisioning having the job call home?  I was<br>
thinking at startup and core reload and if that's the case why bother<br>
with an external process and the work that goes with it?  I know<br>
someone mentioned they don't want asterisk crashing because of a flaw<br>
in the beacon but you can say that about any portion of asterisk.</blockquote><div><br></div><div>The fact that you can say that about any portion of Asterisk is not a good argument for inclusion (or against doing it outside). The more you add in-process, in a low-level language such as C, the bigger the odds a small mistake brings the whole thing down. Also the community that is capable of fixing bugs, auditing code, etc; is smaller than if this were written in a scripting language, very little sys admins would be able to tweak it or hook into it since your average sys admin does not have C knowledge. This is also the reason an application like 'Queue' is better controlled from the outside with Asterisk just providing the telecom building-blocks which *need* the low-level control of C. Reporting occasionally data via HTTP is not something that needs C.</div><div><br></div><div>Having said that, I understand the non-technical argument of remove friction to opt-in to have this functionality enabled and collect more stats, which makes the in-proc option more appealing.</div><div><br></div><div>-</div><div>Moy</div></div></div></div>