[asterisk-app-dev] Changing POST /bridges/{bridgeId}/addChannel

[Matthew Jordan]

On Tue, Oct 15, 2013 at 5:14 PM, Paul Belanger <paul.belanger at polybeacon.com
> wrote:

> On Tue, Oct 15, 2013 at 3:35 PM, David M. Lee <dlee at digium.com> wrote:
> >
> > On Oct 15, 2013, at 12:24 PM, Paul Belanger <
> paul.belanger at polybeacon.com> wrote:
> >
> >> On Tue, Oct 15, 2013 at 1:07 PM, Joshua Colp <jcolp at digium.com> wrote:
> >>> Paul Belanger wrote:
>

<snip>


>
> > And you would have to pass the bridgeId into the DELETE, and passing
> > params into deletes is just freaky.
> >
> Ya, this is still an issue I guess. Can a channel live within more
> then one bridge? I don't think it can right? So, if DELETE
> /channels/{channelId}/bridge asterisk would have to look for said
> channel.  Not sure that is the right approach either.
>
>
Nope. Having a channel exist in multiple bridges would have been cool, but
would have required another year of development (if not more).

There's two reasons why a channel joining a bridge should be an operation
on a bridge, and not a channel:
(1) The first is what you just pointed out: a channel can only be in one
bridge, but a bridge can have many channels. Thus calling addChannel on
multiple channels is acceptable; calling bridge on a channel multiple times
is not.
(2) Following that, from an OO perspective (which we have going with our
resources and their properties/relationships), what changes is the bridge,
not the channel. The bridge assumes ownership of the channel; hence it
should be operations on the bridge that take ownership and release it.
(2)  A bridge is not a state that a channel is in, which
/channels/{id}/bridge implies. A bridge is an object. It has its own
lifetime, properties, and state. Saying "bridge some channels" is actually
a misnomer now: channels are in a bridge, they may have a bridge supporting
them, but the bridge itself is a thing and the channels are just along for
the ride.

I know that's a pretty sharp departure from previous versions of Asterisk,
and goes against the grain of how we think about calls and channels and
bridging: but I think it's important that we reflect that, particularly as
we flesh out more complicated bridge technologies.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131015/03db2299/attachment.html>