[asterisk-dev] Deprecation of cdr_mysql

[Olle E. Johansson]

11 jul 2012 kl. 17:16 skrev Paul Belanger:

> On Wed, Jul 11, 2012 at 10:38 AM, Mark Michelson <mmichelson at digium.com> wrote:
>> On 07/11/2012 09:02 AM, Paul Belanger wrote:
>>> 
>>> On Wed, Jul 11, 2012 at 9:47 AM, Olle E. Johansson <oej at edvina.net> wrote:
>>>> 
>>>> I must have missed the discussion - can someone please explain to me why
>>>> cdr_mysql is marked as deprecated in 1.8?
>>>> 
>>> It started with this review[1] and turned into this wiki page[2]
>>> 
>>> Basically there is a better way to do it (ODBC) and nobody wanted to
>>> maintain the module.  After Asterisk 11 drops, I suspect you'll see
>>> some patches starting to remove some of the deprecated modules from
>>> source.
>>> 
>>> [1] https://reviewboard.asterisk.org/r/1181/
>>> [2]
>>> https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
>>> 
>> 
>> Let me chime in and say that removing deprecated modules is unlikely to
>> occur unless we have a suitable drop-in replacement that we are willing to
>> support.
>> 
> The argument could be made, the reason for it being moved to
> deprecated in the first place was because there is another module that
> can provide the same functionality.
> 
> The reality is this is usually not the case.  Nine times out of ten it
> is because we no longer want to do bug fixes for said module.
> 
> For example, look at app_meetme.  It is a deprecated module in favour
> of app_confbridge, however app_confbridge is not a drop in
> replacement.
Up until now we had the policy of not deprecating stuff that works. and especially
not REMOVE functionality that users use.

Removing meetme without having a drop in replacement would cause a non-developer-friendly
reaction from the user base, which I'm sure that we don't want.

Removing mysql and postgresql just because ODBC has drivers for it doesn't help either.

Talking about mysql, I just found an issue in the realtime mysql driver. It's not reporting errors. I see
in the debug that asterisk failed to update a record, but the manager setvar that use the
REALTIME() function happily reports "success"... Someone forgot to send or read an error code
somewhere in the chain.

Oh well, always cool stuff to do.

/O