[asterisk-dev] Asterisk 1.6 Realtime Database must use ', ' not '|' in appdata field?

[Ward Mundy]

> From: Sean Bright <sean.bright at gmail.com>
>
> Ward,
> So what would you like to see happen with 1.6?  Based on what I have
> read of this thread, the optimal scenario for you and your users is 100%
> BC with Asterisk 1.4 (and possibly 1.2?).  Besides that, what else do
> you envision for 1.6 and beyond?


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.

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.

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.

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.

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 L33t sandbox. Future
development strategies need to take that metamorphosis into account. This
approach doesn't cripple future Asterisk development in any way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080530/db8541c8/attachment.htm