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

[Luigi Rizzo]

On Thu, Mar 09, 2006 at 08:58:17PM +0100, Olle E Johansson wrote:
> 
> 9 mar 2006 kl. 20.50 skrev Kevin P. Fleming:
> 
> > Luigi Rizzo wrote:
> >
> >> so how about an interim solution where we carry on both the old say.c
> >> and the new app_say.c, with a config-file switch to choose which
> >> one, and after a while when we are confident that the new methods
> >> is on par with the old one we get rid of say.c and things
> >> keep working as before (or hopefully better)
> >
> > I don't think there is a reason to do that extra work, unless we  
> > are not
> > confident that we can have the new solution functional and bug free in
> > 90 days or so. If we can, then I say move ahead as quickly as we can,
> > since we are allowed to have a partially broken/non-functional
> > development branch now :-)
> 
> Just a little bit of caution:
> 
> I worked together with some other people a whole summer implementing
> the current syntaxes from a lot of untouched patches in the bug tracker.
> There are quite a lot of stumbling blocks and "aha"s you will  
> discover as

when i rewrote say2.c i discovered a lot of broken code in say.c
which evidently came from cut&paste from other languages.
Some of these were evident even to non-native speakers
(e.g. ast_say_number_full_nl() jumping into ast_say_number_full_en(),
and more similar instances), some evident to native speakers,
issues with date formats not consistent with language-specific
representations and so on.

So, for what matters, i am not confident at all that
the code in say.c -- i do not doubt that providers around
the world have their own patches which may or may not have
been contributed back.

But the huge advantage of a config-file based solution is that
even a non-programmer can spot and fix things, and merging changes
will be orders of magnitude easier.

> you work with this, it's very hard to foresee all cases, different  
> requirements
> and strange syntaxes.

the idea is not try to foresee too much, just provide basic mechanisms.

Then if someone comes up with a requirement like "our clients are
geeks and they say numbers by using the binary representation" and
if there is no better way to implement this, we provide a C hook
(to be called from the config file) to produce the required string
for further parsing.

Honestly i don't expect a huge amount of these exceptions (that
cannot be dealt otherwise using the pattern matching, that is)
to come up, and in any case are so trivially dealt with that they
are not an implementation issue.

	cheers
	luigi