On Thu, 2008-04-24 at 15:03 -0400, Ward Mundy wrote: > Sorry, but I don't think I want to touch that list. I understand where > you are headed, but I think you need to address it as you see fit. > Just reading the questions tells me we are miles apart. OK, I'm confused then, because I honestly don't think we're that far apart. (Maybe I'm just not very good at articulating some things, or maybe you don't believe me on certain points.) I was making an honest effort to try to enumerate the concerns raised in both your post and topic in the forum. I'm not trying to play games here -- If the list of questions I created doesn't address your concerns, then let's start over and try to get to the bottom of this. Would a phone call help? > The major concern that I personally have (and there are some > additional issues that have been expressed by other folks) is that, if > the API is changed, Digium should do one of two things: either support > the old syntax in the API so that nothing gets broken or write a piece > of middleware code separate and apart from Asterisk and the API that > can parse dialplans AND source code to correct syntax which has been > modified in the the API. OK, when you say "API" here, I think you're lumping two different things together, so let me try to separate them and explain them individually. The first is source-code APIs. This is where a third-party program links directly to the Asterisk source code and calls Asterisk functions to perform various tasks, such as parse configuration files. (I'm sure you remember the ast_config_load function from your experience with app_swift.) This is what my earlier two emails concentrated most on, because that's what caused the problems with app_swift. Again, we do *absolutely everything* we can to avoid changing the source-code APIs between minor releases, but there's just no way the Asterisk developers can guarantee source-code API compatibility between major versions. In talking with the developers, they tell me there's usually not even a good way to be able to maintain both the old and new APIs, as usually when the APIs change it's because the underlying code had to be fundamentally rewritten to fix a particular bug or to be able to support a new feature. The best I can say here is that in theory it would be really nice, but it's one of those things that just doesn't work out too well in practice. The second issue is dialplan and CLI syntax changes. I'm not about to tell you that the changes to the syntax weren't painful, because they were (and still continue to be). Please believe me when I tell you that the decisions to make those changes were not easy decisions to make. I liken these changes to a trip to the dentist. Nobody goes to the dentist just for the fun of it, and hopefully the trips to the dentist are few and far between. Unfortunately, your article (and especially the comments and follow-up post on the PIAF forums) seem to imply that Asterisk developers change the dialplan and CLI syntax on a whim or because one syntax looked prettier than another, and that the developers don't care about whether or not the changes affect people writing dialplans. Let me emphasize that nothing could be farther from the truth. Now, before you get all upset by me saying that... let me explain: Off the top of my head, I can think of three instances where the dialplan syntax or CLI syntax have undergone major changes. 1) The first instance was when we went from explicit priority numbering (1,2,3,4) to being able to use the 'n' priority (1,n,n,n). Associated with this was the change of many applications (such as the Dial() application) to set status variables instead of doing priority jumping. I'm not sure if you were using Asterisk at the time, but it used to be that if Dial() called a device and the device was busy, control of the call would go to the whatever the current priority number was plus 101. To be frank, almost nobody complained about that change, as was obviously a better choice, and made for much easier scripting of complex logic. As with all dialplan changes, we deprecated the priority jumping in the next major release, and didn't get rid of it until the next major release. This meant that in effect, you had several years to adjust your dialplans. The CLI also warned that this feature was going away, and that you'd need to adjust your dialplan. These changes were also well-documented, so that people would know what to expect when upgrading their system. 2) The second instance was when we went from everything being an application to having a split of applications and functions. This change got started a little over three years ago (between the releases of Asterisk 1.0 and 1.2), when the developers realized that that certain functionality was better suited to the being functions. That's the change that took the DigitTimeout() application (along with the AbsoluteTimeout() and ResponseTimeout() applications) and turned them into the TIMEOUT() function. The basic idea here was that anything that simply set or retrieved values (but didn't actually effect the audio on the channel) could be turned into a function. In the specific case of the TIMEOUT function, it meant that not only could you set any of the various timeout values, but you could also retrieve them as well (without having to have a from inside the argument to an application, as show here: exten => 123,1,Playback(this-call-is-limited-to) exten => 123,n,SayNumber(${TIMEOUT(absolute)) exten => 123,n,Playback(seconds) I use the TIMEOUT function as an example, as that's the one you specifically mention in your blog post. Remember where you said that you defy anyone to explain why Set(TIMEOUT(digit)=timeout) was an improvement over DigitTimeout(timeout)? Hopefully my little explanation starts to explain why that change was made. In looking back, that change was made almost exactly three years ago, and it generated a fair amount of discussion in the Asterisk community. There were a lot of people (myself included!) who didn't understand why the change was being made, and the developers did a good job of explaining why they thought the changes were necessary. (Feel free to do some searching through the mailing list archives for more information.) For me personally, once I understood why functions were so powerful, I accepted them and never looked back. In fact, I'd have a really hard time going back to the days of not using functions in my dialplan.) Anyway, I hope you see that the change to using dialplan functions wasn't simply made because somebody thought one syntax looked prettier than the other -- it was due to the fundamental shift in adding dialplan functions. Now, just for clarity's sake -- both the function and application were supported for the 1.2 release (with a warning that the dialplan will need to be updated), and then finally the applications were removed for the 1.4 release. All of this was also well documented. 3) The third instance I can think of is the more recent CLI syntax changes. (Let me see if I can do justice to an explanation of this.) About the time Asterisk 1.2 was released, there were a bunch of requests on the developer mailing list to make some changes to the Asterisk CLI syntax. Various ideas were thrown out, including short commands (similar to the Cisco routers) so that you could do something like "di re" instead of "dialplan reload". While that specific suggestion was ultimately rejected (mostly due to the fact that we have tab completion), discussion continued and the decision was made to clean up the CLI commands, as there was little consistency in the various CLI commands. For example, some of the CLI commands were "set " and some were " " and some were set ". In order to clean things up, the developers decided to make the CLI a little more consistent. After much debate on the mailing lists, the format of " " was chosen. Any commmand belonging to the Asterisk core and not another module would be "core ". Thus "sip debug" became "sip set debug" and "reload module foo" became "module reload foo" and "show dialplan" became "dialplan show". While I'm personally not super fond of the order that was chosen, I'd much rather have the CLI commands be consistent than the way they used to be. (And trust me, I think about it all the time when I type "show dialplan" and the CLI tells me that I should be typing "dialplan show" instead.) Again, the decision was made to deprecate the old syntax for a full release cycle before removing the old command syntax, and warnings were provided. Much of the old syntax was marked as deprecated when 1.4.0 was released, and some (but not all) of it will be removed when 1.6.0 is finally released. A long-winded explaination... but hopefully it puts some things in perspective. I know almost every one of the Asterisk developers personally, and interact with most of them on a weekly (if not daily) basis, and I can attest that none of them enjoy changing the syntax. It's not something they delight in doing. But sometimes they feel that it's better to suffer a little short-term pain than to have longer-term problems in the end, just like my dentist analogy. Now let me talk about the good news. The good news in all of this is that I don't see any big changes (of this scope of the three instances I mentioned above) anywhere on the horizon. Hopefully we're getting past most of the mistakes that were made early on in the development of Asterisk, and we're getting to the point where these sorts of changes don't have to happen too often. We just happened to have three fairly major changes in the past five years. Looking toward the future, I'd personally love to see Asterisk get to the point where we could have longer release cycles (or do the Red Hat think where their Enterprise Linux line has long release cycles and five or more years worth of security updates, but Fedora re-releases every six months so that new features can be tried and tested before they go into Enterprise Linux). I say that with my Digium hat off, and just speaking from my own heart. I'm not sure that Asterisk is quite mature enough for that yet -- but I know the developers are actively working on re-working the internal plumbing of Asterisk so that it's in a better position to be able to do that. You see, I'll say again what I've said before -- I think we both want Asterisk to be a rock-solid foundation. It's not perfect yet, and we'll still have a few hurdles to climb before we get there, but I think we're well on our way to get to the goal. It's unfortunate that some of the people who responded in the forums are just now beginning to see the results of decisions that were made sometimes two or three years ago, and I hope they're willing to put up with a little pain in the short term to see a better tomorrow. To use my dentist analogy (as a crutch?) again, my jaw is sore, my cheek us numb, but I'm confident I'm not going to have a toothache in the morning. It also saddens me that the community has fragmented to the point that people seriously think that Digium is out to make life difficult for projects like FreePBX and PBX-in-a-Flash. I'm absolutely amazed at the number of conspiracy theories I've read on the various forums. I'll say for the sake of anybody else who might read this later that Digium wants Asterisk to be best telephony engine in the world, and that they're one-hundred percent dedicated to keeping it free and open. I think the great diversity in the projects that have built up around Asterisk is a testament to both it's flexibility and the open source model, and I believe it's a good healthy thing. I'm happy to see both GUIs like FreePBX and distros like PBX-in-a-Flash flourish and grow. -- Jared Smith Community Relations Manager Digium, Inc.