[asterisk-dev] ARI StasisEnd event vs. channel variables

[Corey Farrell]

On Fri, Oct 21, 2016 at 9:37 AM, Sébastien Duthil
<sduthil at proformatique.com> wrote:
> On 19/10/16 11:59 AM, Mark Michelson wrote:

<snip>

>> I had thought about making the list of channel variables per-ARI app
>> instead of global, but I don't know if that's actually desired.
>
> The underlining question would be: do people use ARI as one big
> application that does all the logic, or do they use ARI as many small
> applications that handle different parts of their logic? In the "one big
> application" case, global configuration is enough. In the "many small
> applications" case, the different applications will probably need
> different variables, and global configuration will clutter the events
> with variables that application mostly don't care about. I guess
> per-application configuration fits better with the philosophy of ARI.
>
> --
> Sébastien Duthil

I'm in favor per app config.  I do not yet use ARI, but when I do I
will have '#tryinclude /etc/asterisk/ari.d/*.conf' in ari.conf.  My
hope is that each ARI app would install it's own config to
/etc/asterisk/ari.d, avoid modification of ari.conf / global options.
Per app config would also be important if dialplan functions can be
added to StasisEnd.

Please also consider the existence of explicit subscriptions to
StasisEnd.  I'm not sure the best way to handle them but assume they
could need access to variables as well.  In situations where we send
StasisEnd events to multiple apps I think it would be better to
generate one packet containing the union of all variables requested by
active subscriptions.  I believe the goal is to minimize overhead of
generating StasisEnd, so generating a unique packet per destination
would be wasteful.  On the other side the overhead of parsing JSON and
ignoring unneeded variables is low.