> > How often were you envisioning having the job call home? I was > thinking at startup and core reload and if that's the case why bother > with an external process and the work that goes with it? I know > someone mentioned they don't want asterisk crashing because of a flaw > in the beacon but you can say that about any portion of asterisk.
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. 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. - Moy
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
