[asterisk-dev] 1.4 and CDRs -- The Breaking Point
murf at digium.com
Thu Feb 5 15:10:14 CST 2009
In short, I'm finding the current CDR system is too difficult
to maintain. I'd rather spend my time rewriting the system
into something that works as advertised, is simple to use,
meets user's expectations, and can be maintained and
understood without an advanced post-doctorate degree.
My plan is to try and solve the current crop of bug filings,
but if the changes are too invasive, reach too far down into
the core of asterisk, or would cause bad enough regressions
(which I often can't predict!) -- I would like to close them
as "can't fix", or "will fix in 1.6.x".... and I'd like to
spend more of my time writing up a practical, working
alternative, and let the 1.4 CDR related code rest so folks
can either adapt to it, work around it, etc.
The current crop of CDR bug reports fall roughly
into these categories:
1. undesired behavior when the disposition is
"Not Answered/Failed/etc". (a "ripple effect"
(regressions caused by previous "fixes").
2. undesired CDR times on transfers.
I have promised to do what I can, but this can't go on.
I'm applying bandages to an architecture that needs to
be rebuilt to get things right. This is *software*, and
yes, I can fix *every* problem, but the cost
is way beyond what's reasonable.
What I'm aiming for is a system that is "monolithic"
(all done in one place) vs. "inline" (operations performed
in several spots in the code, usually while doing other
related things). I want test suites that I can run offline.
I haven't written the code yet, but I'm pretty sure I
can get all this with the CEL base. And, I'm writing a
spec for the system, so it can "work as advertised".
"svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs"
to get .doc, .docx, or .pdf file with the current draft
Is what I'm proposing OK?
Steve Murphy <murf at digium.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090205/8cce9c83/attachment.bin
More information about the asterisk-dev