[asterisk-dev] 1.4 and CDRs -- The Breaking Point

[Steve Murphy]

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".
(Do 
"svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs"
to get .doc, .docx, or .pdf file with the current draft
spec)


Is what I'm proposing OK?

murf


-- 
Steve Murphy <murf at digium.com>
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090205/8cce9c83/attachment.bin