FreeTDS Development Group

[Brian Bruns <brian AT bruns.com>]

Oh also, I'll mention again that I maintain a github mirror of the CVS tree

https://github.com/brianb/FreeTDS

It has all the CVS revisions back to the beginning (or at least since
we moved to sourceforge).  It's up to date if anyone wants to use that
as a starting point for the git move.

Brian

On Thu, Aug 18, 2011 at 4:03 AM, Frediano Ziglio <freddy77 AT gmail.com> wrote:
> Well.. we just released new version, time to start a new roadmap.
>
> - repository
>
> I think it's about an year I don't write to ChangeLog directly and
> months I don't use CVS, is time to officially switch to a more
> featured VCS. After some discussion Mercurial and GIT was selected.
> Now I think we decided to use GIT we are estimating public providers,
> SF/GitHub/whatever. Finally we would even rename files!
>
> - return code
>
> mostly libTDS functions return TDS_SUCCESS/TDS_FAIL while other
> returns other ranges for success and fail (like convert that return
>>=0 for success and < 0 for fail). Other functions can return
> TDS_NO_MORE_RESULTS/TDS_CANCELLED, others other values, we test for
> TDS_SUCCESS, for TDS_FAIL. I'm planning to unify the situation but
> there are some problems due to some relationship between dblib/ctlib
> values (like assumption TDS_FAIL == CS_FAIL or same constants for
> tds_error). Patches are quite ready.
>
> - thread
>
> libTDS is far from fully thread safe. It returns results filling
> fields in a structure without any lock. Currently test to change
> connection state is unlocked. Locking at upper layer lead cancellation
> a problem. I have some patches for odbc thread safety, but not for
> cancellation. Also posting data over an encrypted connection while
> waiting for read from a different thread (one of possible cancel
> situation) lead thread problems on TLS layer. I'm thinking a way to
> release a mutex before poll in order to be able to write or another
> way to signal main thread (probably using a socketpair, the most
> portable and signal safe implementation).
>
> - mars
>
> patches are undergoing but raise thread problems. I think is useful
> only for ODBC.
>
> - bcp
>
> port to ODBC. Better testing, even for new types. It would be great to
> support streams in order to pipe then, at least with prefix format.
>
> - DBD::ODBC and SQLDescribeParam
>
> It's not a secret that DBD::ODBC require SQLDescribeParam to pass all
> tests. It's not a secret that mssql does not support getting
> parameters types but lead the problem to library which has to parse
> sql syntax in order to inference them.
>
> - tds 7.3 (sql 2008 support)
>
> Undergoing, latest patches for ODBC are quite ready. Currently
> ctlib/dblib are limited to tds 7.1 (sql 2000) due to varchar
> conversions and some BLOBs feature removed from upper protocols. I
> think is time to diverge from proprietary library to support new
> protocols.
>
> - ipv6 ?
>
> A patch was posted time ago. I think is time to review it putting in a
> good shape.
>
> - cmake ?
>
> windows support are currently a nightmare due to different environment
> of this platforms. cmake would be a solution. Curl use it and has
> similar portability problems.
>
> - others
>
> ??
>
> Frediano
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>