Re: What's next?

Hi,

Congratulations for the release!

Because I need IPv6 support, I'll probably soon implement it for ODBC. 
I'll check the mail archive for the patch.

Hristo
________________________________________
From: [email protected] [[email protected]] On Behalf Of Frediano Ziglio [[email protected]]
Sent: Thursday, August 18, 2011 11:03
To: FreeTDS Development Group
Subject: [freetds] What's next?

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
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds