[asterisk-app-dev] ARI Global Data Accessibility Changes

[David M. Lee]

On Oct 25, 2013, at 1:48 PM, Paul Belanger <paul.belanger at polybeacon.com> wrote:

> So, in a more general term, we are talking about creating some sort of
> filtering / query system for a bulk get. But rather then just
> channelId, why not expose every parameter. So, if I want to see all
> the up channels, I just pass state=up or specific channel types
> name=SIP.  Personally, I think it gets complicated fast, and not sure
> that's what the issue you are trying to solve is.

Well, I do see a difference between retrieving information by id
(in which you know that at most one object has that id) and filtering
(where any number of objects may match the filter). However, over
time, I can see us adding any number of query filters to our GET
operations that return lists.

I don't think that means we have to add all of them right now; just
the ones we have use cases for.

> I think the bigger issue is trying to determine if the channel lives
> in stasis or not. I think the way to get around that, is add a new
> field to channel call stasis (boolean), and just toggle true or false.

There is tension in the API; two competing concerns.

The first concern is to make the API simple and easy to use. The
problem with it currently is that many operations will give you
information about objects you can't manipulate via ARI. This goes
beyond "is the channel in Stasis". It's really more about "is
this information useful". This is the concern addressed by Kinsey's
proposal.

The second concern, though, is to make the API powerful. There are
certainly use cases where an application will want to monitor the
status of things outside of itself. Hence my counter-proposal: make
the API merely useful by default, but have options to make it more
powerful.

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org