[asterisk-dev] Adding new ARI subscription type(topic)

[Joshua C. Colp]

On Thu, Mar 7, 2019, at 8:13 PM, Sungtae Kim wrote:
> Hi Asterisk team,
> 
> I want a talk about some new feature for the ARI(stasis application).
> 
> It's about the subscribe/unsubscribe the arbitary topics from the ARI.
> 
> I was thinking about similar feature before. 
> (https://issues.asterisk.org/jira/browse/ASTERISK-28227)
> 
> And I was talking about the module at the moment, but I want a talk 
> about topic, not a module.
> Because it's much more make sensible.
> 
> Currently, to sending a message to the stasis application, there's 3 
> ways to send it.
> By channel, bridge, endpoint's topic. So, if someone want to more ARI 
> resource, it's not an easy to
> send a notification message.
> 
> So, I was thinking it would be good to if the stasis can subscribe the 
> other topics.
> 
> 
> AS-IS
> 
> asterisk*CLI> ari show app pchero_voip
> Name: pchero_voip
>     Debug: No
>     Subscription Model: Global Resource Subscription
>     Subscriptions: 3
>       Channels:
>         __AST_CHANNEL_ALL_TOPIC (1)
>       Bridges:
>         __AST_BRIDGE_ALL_TOPIC (1)
>       Endpoints:
>         __AST_ENDPOINT_ALL_TOPIC (1)
> 
> TO-BE
> 
> asterisk*CLI> ari show app pchero_voip
> Name: pchero_voip
>     Debug: No
>     Subscription Model: Global Resource Subscription
>     Subscriptions: 4
>       Channels:
>         __AST_CHANNEL_ALL_TOPIC (1)
>       Bridges:
>         __AST_BRIDGE_ALL_TOPIC (1)
>       Endpoints:
>         __AST_ENDPOINT_ALL_TOPIC (1)
>       Others:
>         Queue:sales1
>         Queue:sales2
>         Voicemail:test01
>         Agent
>         ...
> 
> 
> With this design, the stasis app can subscribe entire of topic or 
> specified topic, like
> subscribe Queue or Queue:sales1.
> 
> What do you think?

I personally don't think that allowing subscription to arbitrary topics is a good idea. This tightly couples the ARI application with an implementation detail inside of Asterisk, and doesn't enforce any kind of documentation. To ARI applications they should just have to specify "I want to monitor Queue:sales1". Now, ARI internally will turn this into the appropriate topic and subscribe them - but that's an implementation detail of ARI, and not something the ARI application has to care about.

To me ARI is the layer in between the complexity of Asterisk and also its implementation details. It's good for the ARI application developer because they don't have to care/know generally how many things work, and it also benefits the Asterisk side because changes can be made without impacting the ARI application developer.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org