[asterisk-dev] bugs a plenty - discuss....

[Luigi Rizzo]

On Wed, Mar 08, 2006 at 01:19:01PM -0600, mogorman wrote:
> Hi everyone
...
> remove dependenices on res_adsi.so in app_voicemail.so and others
> http://bugs.digium.com/view.php?id=5930
>     adds stub functions for res_adsi much like res_crypto has and 
> res_musiconhold.  Should this just be held till rizzos new loader is 
> implemented?

i think that at least stubs for the main API functions should
always be available irrespective of whether the module is
loaded or not. So even if i haven't seen (no web access at the moment)
the details of the change, i think they should go in irrespective
of the loader stuff.

> Say syntax in Russian
> Japanese SayNumber functionality
> New App Saynumber, for generic way of easy internationalization
> http://bugs.digium.com/view.php?id=6207
> http://bugs.digium.com/view.php?id=5933
> http://bugs.digium.com/view.php?id=4983
>     Any non-english speakers here?  It seems these patches have stalled.

the problem here is on the lead architects which have to state
what they want before we can move on.

In my opinion the only sensible way to implement internationalization
is the table-based approach, which will let us get rid of
some 5000 lines (the difference in size between say.c and say2.c)
of unmaintainable C code and replace it with a few tens of
lines in an highly maintainable ascii config file for each language.

There is a sample of this in my team/rizzo/base branch
as an extension to app_playfile (just because it was a convenient
placeholder) and configs/say.conf.sample . If you look there,
the C implementation and the config files are trivial and short.

We have already a lot of well tested code to parse config files,
provide an include-like mechanism, and access it from within the C
code in a highly structured way. We should make use of it.

The same approach should be used for things like voicemail;
it makes no sense to hardwire decisions in large chunks of C
code when the same things could be easily done using tables
and config files.

Remember that the extra overhead is negligible: each of these
interactions typically requires demuxing and parsing a SIP/IAX message
or dtmf tone, and then opening and streaming a file. Adding
a few hundred CPU cycles to browse through a short in-memory
list of things to do is hardly measurable in comparison.

> improper handling of contexts with same name
> http://bugs.digium.com/view.php?id=6002
>     Currently there is an issue with the regcontext, regexten 
> implementation that allows for multiple extensions with the same 
> context, exten , and run level.  This is a big problem.  Currently a 
> hack was used to make this far less noticable but this is still a problem.

once again the ball is to the main architects.
The report indicates two possible solutions.
Settle on one and i am happy to implement it.

	cheers
	luigi