gmane.comp.telephony.pbx.asterisk.devel

Sean Bright | 17 Aug 15:00

Asterisk 1.4 with cdr_tds and FreeTDS 0.82

The existing implementation of cdr_tds in Asterisk 1.4 uses libtds,
which is part of the FreeTDS package.  libtds has always been considered
a non-stable API, and developers were encouraged to write their
applications against either the db-lib or ct-lib front end.

With the release of FreeTDS 0.82, libtds is no longer installed by
default, which results in Asterisk's build system not being able to find
FreeTDS and therefore not build the cdr_tds module.

I know that this is not technically a bug in Asterisk, but considering
that we still have users installing the 1.2 series of Asterisk (at their
own peril) I am concerned that users will run into this problem with the
1.4 series for, well, a years.

While I would be satisfied simply documenting that Asterisk 1.4 will not
work with versions of FreeTDS newer than 0.64, the other option is to
move the changes made in trunk (changing cdr_tds to use db-lib) into the
1.4 branch, even though we are feature frozen.  Note that there is no
behavior change in the trunk version, we simply changed which API we
were coding against.

Thoughts?

Thanks,
--

-- 
Sean Bright
sean.bright <at> gmail.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

(Continue reading)

headers

Venefax | 17 Aug 15:18

Re: Asterisk 1.4 with cdr_tds and FreeTDS 0.82

I support this idea and I also open a bug yesterday on the issue 13328. We
need to get rid of freetds 0.64, and move the changes in Trunk back to 1.4.
I think that using freetds to store the cdr is far more reasonable that
using ODBC, since ODBC rides on top of freetds anyway, i.e., constitutes an
additional layer of complexity. Furthermore, ODBC has a huge memory leak.
Since I switched from  cdr_odbc and func_odbc back to cdr_tds and routing
via perl-freetds, my memory consumption is stable.

-----Original Message-----
From: asterisk-dev-bounces <at> lists.digium.com
[mailto:asterisk-dev-bounces <at> lists.digium.com] On Behalf Of Sean Bright
Sent: Sunday, August 17, 2008 9:02 AM
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Asterisk 1.4 with cdr_tds and FreeTDS 0.82

The existing implementation of cdr_tds in Asterisk 1.4 uses libtds,
which is part of the FreeTDS package.  libtds has always been considered
a non-stable API, and developers were encouraged to write their
applications against either the db-lib or ct-lib front end.

With the release of FreeTDS 0.82, libtds is no longer installed by
default, which results in Asterisk's build system not being able to find
FreeTDS and therefore not build the cdr_tds module.

I know that this is not technically a bug in Asterisk, but considering
that we still have users installing the 1.2 series of Asterisk (at their
own peril) I am concerned that users will run into this problem with the
1.4 series for, well, a years.

While I would be satisfied simply documenting that Asterisk 1.4 will not

(Continue reading)

headers

Russell Bryant | 18 Aug 16:25

Re: Asterisk 1.4 with cdr_tds and FreeTDS 0.82

Sean Bright wrote:
> The existing implementation of cdr_tds in Asterisk 1.4 uses libtds,
> which is part of the FreeTDS package.  libtds has always been considered
> a non-stable API, and developers were encouraged to write their
> applications against either the db-lib or ct-lib front end.
> 
> With the release of FreeTDS 0.82, libtds is no longer installed by
> default, which results in Asterisk's build system not being able to find
> FreeTDS and therefore not build the cdr_tds module.
> 
> I know that this is not technically a bug in Asterisk, but considering
> that we still have users installing the 1.2 series of Asterisk (at their
> own peril) I am concerned that users will run into this problem with the
> 1.4 series for, well, a years.
> 
> While I would be satisfied simply documenting that Asterisk 1.4 will not
> work with versions of FreeTDS newer than 0.64, the other option is to
> move the changes made in trunk (changing cdr_tds to use db-lib) into the
> 1.4 branch, even though we are feature frozen.  Note that there is no
> behavior change in the trunk version, we simply changed which API we
> were coding against.
> 
> Thoughts?

What about including the new module from trunk as an alternative that 
isn't enabled by default?  That way, you don't risk breaking anything 
that is working just fine with the existing module.  Then, just include 
a blurb in UPGRADE.txt and perhaps the sample config file about it.

--

--

(Continue reading)