freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>
- To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
- Subject: RE: Proposed change
- Date: Mon, 28 Oct 2002 16:28:53 +0100
>
> I don't understand...can you elaborate some more on what you
> want to do, and
> why?
>
ok
>
> 1) header
> Why we do not remove the need for tds.h. I think we can
> redeclare needed
> structure and constant and check that those structure are the
> same during
> compile process.
>
The intention is to use tds.h only for accessing to libtds, not for ctlib or
dblib (odbc use always his headers).
Now including ctlib header you include all libtds stuff information.
> 2) snapshot build
> I think we should update our snapshot build process. Now the only build is
> CVS snapshot. I'd like to add
> - documentation snapshot (so test users can try using update documentation
> removing the need of docbook)
> - rpm snapshot (built every day)
We distribute a daily snapshot of CVS. But we update also documentation. I
think we should compile documentation every day and distribute it too.
Other think is libtds documentation. I don't know how many user/developer
use doxygen generated documentation but perhaps even this documentation
should be published somewhere.
> 3) distribution
> Why do not use a date instead of a version for releasing snapshot. So we
can
> release snapshot always with updated version
Usually after publising a new version of a project the first thing I do is
update the version. So all future version use an updated version. If you
bring current CVS version and compile it you obtain a "0.60" version, but
this is not version 0.60 (is a CVS post 0.60 version). Some project use the
date (as 20021028 for current version) for CVS versions.
> 4) new compile options
> Personally I hate debug code in release so I'd add a --minimun-debug-level
> for disabling some debug/log code generation.
> Other option is to disable the read of environment variable for connecting
> configuration (like TDSHOST, TDSVER), it seem a bit unsecure...
There are many debugging code (all calls to tds_dump_log). This info are
useful for developer but useless for end user (in production). Disabling the
compilation of some debugging info is useful.
Environment. You can override all important connection setting and dumping
with with environment variables... What happen if we set TDSDUMP so we can
read crypted password from log file? What happen if we call the program
setting TDSHOST/TDSVER with appropriate values? Malicious code can force
program to connect to whatever server we want...
freddy77
=================================
"STRICTLY PERSONAL AND CONFIDENTIAL
This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."
=================================
-
Proposed change,
ZIGLIO Frediano, 10/28/2002
- <Possible follow-up(s)>
- RE: Proposed change, Castellano, Nicholas, 10/28/2002
- RE: Proposed change, Lowden, James K, 10/28/2002
- RE: Proposed change, ZIGLIO Frediano, 10/28/2002
- RE: Proposed change, Castellano, Nicholas, 10/28/2002
- RE: Proposed change, ZIGLIO Frediano, 10/28/2002
- RE: Proposed change, Lowden, James K, 10/28/2002
- RE: Proposed change, ZIGLIO Frediano, 10/28/2002
Archive powered by MHonArc 2.6.24.