[Asterisk-code-review] res/res_ari_channels.c: Added new ARI /ari/channels/<channelId>/dump (...asterisk[master])

[sungtae kim]

sungtae kim has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/11162 )

Change subject: res/res_ari_channels.c: Added new ARI /ari/channels/<channelId>/dump
......................................................................


Patch Set 1:

> Patch Set 1:
> 
> I'm concerned with these additions to ARI that they don't have an over all goal for it. I'm not against changing ARI, but I find that we have to be careful with it and not just add things because they're missing or could be useful. This can end up complicating ARI or exposing internal details that shouldn't be exposed. I find the best way to approach it is to have an end goal (for example better monitoring) or use case and approach it from the perspective of an end user who has no idea of the internal details of Asterisk itself (or the DumpChan application in this case).
> 
> To that end, what is driving this change? Better monitoring like I gave an example of?

Hi Joshua,

Thank you for your kind reviewing. :)
I'm totally agree with you. Changing something without context or detail use-case, it makes easy to loosing the direction.

I expect the ARI user can get a detail/debug info for ARI programming(channel) with this change.

It was little bit hard to obtaining the Channel's detail info using ARI. To getting detail info, it has to be done by the AMI or dialplan.

But for the ARI user, it's not an easy to use another interface for that. As an ARI user point of view, I want to stick to the ARI as long as possible(I love AMI, AGI, and Dialplan, but the ARI makes every problem so easy).

For example, in the situation of start/restart the stasis application(which is connected
to the Asterisk), I needed to follow up the existed channel's detail information. And also I want to get these information (answered time, application, application data, format and so on) throught ARI, to checking the status time to time.

That was the reason why I want to add this feature.

p.s.
This would be different story, but I think if the ARI working as AMI, it will gives more flexibility to the Asterisk in the long long after future. :)

what is driving this change?
-> To follow up the Channel's information
-> To obtain more detail(debug) information for ARI programming


-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/11162
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: Ie5b6c8b20a2bda5168ea56114f4241bc818cab10
Gerrit-Change-Number: 11162
Gerrit-PatchSet: 1
Gerrit-Owner: sungtae kim <pchero21 at gmail.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: sungtae kim <pchero21 at gmail.com>
Gerrit-Comment-Date: Tue, 19 Mar 2019 22:32:55 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20190319/30426a13/attachment.html>