On 14 Mar 2014, at 21:29, Jared Smith <jaredsm...@jaredsmith.net> wrote:
> > On Thu, Mar 13, 2014 at 3:34 PM, Olle E Johansson <reviewbo...@asterisk.org> > wrote: > For every poorly designed bad feature I can think of I can find a large > number of Asterisk users that want it. It's simply not a good argument. We > create this software and need some sort of architecture when we do. > I think you're being a bit extreme here, Olle, and your email sounds (at > least to my ears) as being quite demanding. You could use this same argument > to shoot down *any* new feature or code. I know you're still focusing on > Asterisk 1.8 and taking care of your paying customers (at least the last time > we talked), but from my vantage point the whole reason we're going to down > the road of pjsip and a new SIP channel driver is to have a better > architecture, and these DNS changes are one part of a whole series of changes > specifically designed to improve the architecture. What have the entire > Asterisk 12 and 13 development cycles been about if not for improving our > architecture? I haven't in any way said that it was a bad to go down this route, Jared. > The current DNSmanager is broken in so many ways I can't even begin to > describe it and it is not asynch, asterisk still stops if we're not getting > an answer. > I agree one hundred percent. That's why it surprises me that you're coming > out so vehemently about an improvement -- any improvement -- to the way we > handle DNS. Now I agree that it's not ideal to have two different ways to > resolve DNS in different parts of Asterisk -- but that being said, I think > *any* improvement is a step in the right direction. Adding this code to > pjsip doesn't make chan_sip any worse. I haven't been against ANY DNS improvements - that is something other people have talked about, not me. I am primarily against including a way to configure DNS servers in a module of a larger product, and secondarily against including a DNS resolver in a module of the same product. I have made those statements very clear in many mails and reviewboard - you even quoted it below. > > Even if it can ba done easily, doesn't mean it's right. We do need to manage > our product. Adding the ability to configure a different set of DNS servers > for a module or even a full server application is a bad thing. That's the > first part we should not do. After that, we need to fix our DNS architecture. > OK, I can't speak about managing a "product", because this not a product to > me. I don't get that. > It's a tool that I happen to use. I leave it to others to productize it. On > this mailing list, however, I feel we should focus on development of Asterisk > as a toolset, and leave product discussions for other venues. > > If you have suggestions on how to "fix our DNS architecture" as you say, in a > way that is not only asynchronous, respects TTL (and refreshes results again > once the TTLs have expired), handle SRV records correctly (including > sorting), and solve the happy eyeballs/earballs problems, I'd love to see the > code get incorporated into Asterisk. In the meantime, the proposal in front > of us seems to be a step closer than what we have today. It may not be > perfect, but I think there are more serious sins than allowing an end user to > shoot themselves in the foot. (We already give them plenty of firearms and > ammunition with the wide range of configuration options and files and modules > available today.) You are writing the mail in a way that puts words in my mouth that hasn't been there. I am not against Asterisk improvements, or the PJSIP channel driver, DNS improvments or the way we manage our project. I am worried when developers add stuff that will break our architecture just because it is possible to do with a third party library and thus giving us a lot of future support. No one has stepped forward with a good reason to add DNS servers to the pjsip config file, a real problem it solves. /O
-- _____________________________________________________________________ -- 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
