[asterisk-dev] Violent Objections? CDR dst/dcontext probs in 1.4+ when a macro is involved.

[Tilghman Lesher]

On Tuesday 03 July 2007 15:30, Tzafrir Cohen wrote:
> Why not just add capabilities to the existing module? Why add a
> separate module?

Because people prefer to have things continue to work, and these changes
necessitate a fairly major change, in the addition of a configuration
file or changing how the configuration file is structured.

> > It's more a matter of actively defining the migration path, than of
> > active duplication. We've just chosen the 'easy' path for now.
>
> Is it the easy migration path? Suddenly an extra configuration file
> with a strange name was introduced. "custom" and "adaptive" don't
> really describe the CDR recording itself. You will eventually need to
> get rid of the name.

"adaptive" does indeed describe how it works.  For that matter "ODBC"
doesn't describe the CDR recording itself, either, but also how it
works.

Nothing says we couldn't transition the names, though I'm sure the old
module will continue to exist with another name (cdr_old_odbc?) for a
version, to ease the transition.

> A different and better example: The name "iax*2*" is sadly still
> here, but the config file is called "iax.ocnf" and not the strange
> "iax2.conf".

That was with a transition, where both filenames were recognized as
valid, for a period of time.  The problem with changing the name of the
protocol is that I'm sure IAX1 still exists to some extent, and we'd
like to avoid confusion, as best as possible.

Actually, there's no reason why we couldn't rename chan_iax2.c to
chan_iax.c.  We just haven't done it yet.  However, I don't think we're
ever going to stop calling it IAX2 until an incompatible protocol
change is released and we'll start in on "IAX3".

> And of course: are bugs fixed in both?

Yes, but the source to cdr_odbc and cdr_adaptive_odbc are completely
unrelated, so fixing something in one doesn't aid you all that much in
finding bugs in the other, any more than finding bugs in app_voicemail
helps you in finding bugs in app_queue.

> > We could easily upgrade all the existing back ends (where 'easily'
> > is a matter of relativity), and mark all the existing backends as
> > deprecated, and remove them in a release or two.
>
> (What I wrote is irrespective to the question of whether this should
> be changed in the CDR core or in the backends, about which I really
> can't add anything useful)

The core is adequate at this point.  What needs to happen is for the
backends (finally) to take advantage of the CDR core features that have
been there since 1.2 was released.

-- 
Tilghman