> From: Sean Bright <<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>><br>><br>
> Ward,<br>
> So what would you like to see happen with 1.6? Based on what I have<br>
> read of this thread, the optimal scenario for you and your users is 100%<br>
> BC with Asterisk 1.4 (and possibly 1.2?). Besides that, what else do<br>
> you envision for 1.6 and beyond?<br><br><br>
Glad you asked. Jared Smith and I already have had this discussion, and I know he has shared some of this with many of the folks inside Digium already. For the benefit of others, let me try to set out some of the issues that have been raised and propose a few solutions. <br>
<br>There are two main areas where code changes in Asterisk directly impact what I would call Asterisk applications. By Asterisk applications, I mean business applications, e.g. systems such as a medical office PBX that calls patients automatically using a scheduled appointment database to remind them of their next doctor's appointment. Another example would be a hotel system that provides customers with voicemail and wake up calls, tracks customers' long distance phone calls and posts the entries to an accounting system, and manages and tracks maid service in individual hotel rooms using an IVR hooked to a MySQL database. A third example would be an emergency warning system that calls everyone in a community and plays a prerecorded message to warn them that a tornado will be coming down Main Street in about 20 minutes. None of these organizations typically have "a phone guy" on site. And most probably don't even have one on the payroll. The organization in all likelihood purchased a canned system, or they may have hired someone to build it in the case of a large hotel chain. But, as a rule of thumb, finding the original application developer would be difficult, if not impossible, two years down the road much less ten years from now. They all have one thing in common. They want their phone systems to continue to work.<br>
<br>So... the two areas where code changes in Asterisk affect these systems are API changes and CLI/dialplan syntax changes. An example of an API change would be
the ast_config_load function which, I am told, now requires that an additional parameter be passed. This broke most of the text-to-speech interfaces to Asterisk, specifically Flite and Cepstral. Cepstral got fixed pretty quickly. It's commercial software. Flite probably never will be fixed because the original developer is long gone. How could this have been avoided? Pretty simple really. Create a new function with the additional parameter instead of breaking code that depended on the old one. And, no, it wouldn't have to be named ast_config_load2 or ast_config_load99. And, no, it wouldn't mean supporting 100,000 functions down the road.<br>
<br>An example of the CLI/dialplan syntax change would be this thread, i.e. making an AGI function call now requires that parameters be separated by commas instead of vertical bars. More egregious were the changes in CallerID syntax between Asterisk 1.2 and Asterisk 1.4 which broke almost everyone's dialplans. There are two different ways to address these changes. The first would be to support the alternate syntax in the code for a much longer period of time, e.g. 10 years instead of 1-2 years. I would note that I still have DOS database applications I wrote in 1985 that run perfectly well under Windows Vista. A second alternative would be to create a middleware application that translates the old syntax into the new one. For most of the dialplan carnage, this would have been relatively easy, e.g. the CallerID stuff, the timeout functions, and changing |'s to commas. <br>
<br>So, if I were King... my request would be that if someone introduces new code that creates a new syntax in the language and removes an old way of doing things, that same person is responsible for providing the code to support the old syntax or, in the alternative, writing a middleware module to update existing source and dialplan code to accommodate the new syntax. This approach also would encourage developers to be more conservative in introducing changes that break existing application code. With over a million downloads, Asterisk is way past being a <font size="-1">L33t</font> sandbox. Future development strategies need to take that metamorphosis into account. This approach doesn't cripple future Asterisk development in any way.<br>
<br><br>