On Thu, Mar 6, 2014 at 4:32 PM, Damien Wedhorn <[email protected]> wrote:
> On 07/03/14 08:21, Matthew Jordan wrote: > > On Thu, Mar 6, 2014 at 3:42 PM, Damien Wedhorn <[email protected]> wrote: > >> On 07/03/14 07:29, Matthew Jordan wrote: >> >> On Thu, Mar 6, 2014 at 3:22 PM, Paul Belanger < >> [email protected]> wrote: >> >>> On Thu, Mar 6, 2014 at 3:31 PM, George Joseph >>> <[email protected]> wrote: >>> > >>> For me to be on-board with the change, we'd have to apply it to all >>> channel drives that implement said codecs allow / disallow logic, so >>> sip.conf, chan_ooh323.conf, gtalk.conf, h323.conf, iax.conf, >>> jingle.conf. >>> >>> That way all our documentation / functionality is consistent among >>> channel drivers. >>> >>> >> Yeah... that will never happen. >> >> I assume this is about the codecs option. If so, why couldn't it be >> implemented in all the channel drivers. Surely the "codecs list" option >> could be a simple wrapper for "disallow all, allow list". >> > > Damien asked me about this in #asterisk-dev, and I should apologize here > - that was a bit of a glib response. > > The reality is that some channel drivers have active maintainers, and > core changes that are made (or 'better ways of doing things') do get > actively made in those channel drivers. This is the case with chan_skinny, > chan_ooh323, and chan_unistim. The channel driver maintainers have done an > excellent job working together with the community to keep up with the > changes in Asterisk 12. > > Others, however, have no active maintainer. This doesn't mean they never > get a bug fix, or that they are broken in Asterisk 12, but it does mean > that there is no one who actively works to keep the channel driver working > with all of the latest changes. > > During Asterisk 12, we spent a lot of time working through all of the > channel drivers for the changes in the Asterisk core. If we hadn't done > that, they would have been broken by the transfer, pickup, and parking > changes. I think that's a fair requirement on the project: if you make a > change in the core and it breaks someone, it's on you to go fix it. > > The question then becomes: do we limit any changes to supported channel > drivers if we do not reflect those changes in an unsupported channel driver? > > I don't think that's a fair requirement. It burdens the project: any > incremental improvement in chan_pjsip, or chan_sip, or any channel driver > really - has to be reflected across all channel drivers. And not all > channel drivers are equal: making a configuration change in chan_pjsip is > vastly different then making that change in chan_dahdi. > > So: no, I don't think it's correct to require non-breaking changes to be > propagated over to all other channel drivers. > > Matt > > > Thanks Matt > > A couple of observations. While I agree with your general advice of not > restricting changes where consistency can't be done, where reasonably > trivial (eg, setting codecs as an alias for any channel driver using > allow), it would be nice to try and make such changes consistent. > > I guess it becomes a matter of where do you draw the line in the sand. > Basically, if a change is going to be made, other drivers should be > considered. > > The second thing, I only picked this up by luck. A couple of words caught > my eye as I deleted a PJSIP email not relevant to my stuff. It may be worth > considering how this type of information can be reliably shared to > interested parties. > Really, the asterisk-dev mailing list *is* the appropriate place for this kind of information to be disseminated. It's the heartbeat of development in Asterisk - we just have to make sure we keep using it :-) -- 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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
