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
