On Fri, Oct 25, 2013 at 10:14 AM, David M. Lee <dlee at digium.com> wrote:
>
> On Oct 24, 2013, at 4:18 AM, Daniel Jenkins <dan.jenkins88 at gmail.com> wrote:
>
> +1 - I'd still want to be able to access information about the whole system
> though - whether this is done with extra headers, as having filtering type
> stuff via params just doesn't feel right
>
>
> I've been giving this some thought. Here's my proposal:
>
> The container list operations (GET /ari/bridges, GET /ari/channels),
> when no parameters are given, will only return the objects that can be
> acted upon via ARI.
>
> However, a specific list of objects can be requested by passing in an
> id list parameter (GET /ari/channels?channelIds=1234,5678,1357,9753).
> These objects will be returned if they exist, regardles of whether ARI
> can act upon them.
>
> Similarly, single object requests (GET /ari/channels/{channelId}) will
> always return that specific object if it exists.
>
> Thoughts? Objections?
>
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.
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.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
