FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > I think is time for a RC... step are usually
> > 1- cvs tag -b BRANCH0_XX (should be cvs tag -b BRANCH0_82, 
> Am I right?)
> > 2- update configure.ac changing version to 0.82rc1
> > 3- update userguide.sgml
> > 4- package, publish and announce new version
> > 
> > I can manage steps 1 to 3 by myself.
> 
> Excellent.  I've been waiting to hear you say you're ready.  
> I didn't want
> to branch a release while you were in the middle of a bunch 
> of changes. 
> 
> Please go ahead and branch BRANCH0_82.  Yay!  
> 
> One thing I'd like to do first.  You truncated ChangeLog and moved the
> 2007 updates to another file.  I think our year-by-year 
> scheme isn't that
> good.  Instead, let's have a release-by-release scheme.  
> 
>       ChangeLog:      changes in CVS HEAD since the last release
>       ChangeLog-0.82: changes since 0.64
>       ChangeLog-0.64: changes since 0.63
>       etc. 
> 
> We don't have to go back and recreate all the old ones.  But 
> I think it
> would be good to create ChangeLog-0.82 now.  
> 

I mainly split between years cause committing ChangeLog every time was
starting to be a nightmare...
I don't know if automake require a ChangeLog but I think we can put a
"See ChangeLog-xxxx" line...

> > It's also a good time to start planning for next release!
> > 
> > Ideas/big TODOs:
> > - support for mssql 2005 (MARS, varchar(max) and so on)
> > - wide characters in ODBC
> > - refactor Makefiles using GNU make
> > - refactor token.c splitting token handling from upper managing
> > - improve multiple request support by libTDS and upper layer
> > - limit copy of data
> 
> Good ideas all, except I want to continue to support BSD 
> make.  I don't
> see any reason not to.  
>  

Is that I don't know if BSD make have some extension that could make
no-recursive make easy to develop.

I found a good way to have customizations within directory. Using GNU
make you can have things like

src/odbc/unittests/% : CPPFLAGS += -I$(ODBC_INC)

that is: if target is in directory src/odbc/unittests add -I$(ODBC_INC)
to CPPFLAGS !! Simple and working!!

> > As you can note I have no plans for dblib/ctlib
> 
> I do, but I'm not sure when I'll get around to it.  
> 
> BLOB handling is a problem.  We make too many copies.  It 
> doesn't matter
> with normal columns, but BLOBs can exhaust virtual memory.  
> 

I know...

> bcp_moretext is the last essential bcp feature.  locale and bcp still
> needs some attention, too.  
> 
> I hope the splitting out the token handling leads to a more 
> rational API
> for libtds.  I really don't like the bitwise OR flags to tell 
> it when to
> return.  
> 
> > - limit copy of data
> 
> An idea about allocation.
> 
> In db-lib -- I don't know if ODBC has a similar feature -- data can be
> fetched with bound columns (dbbind) or not (dbdata).  For 
> bound columns,
> the client allocates a buffer for the data.  When libtds 
> fetches a row, it
> needs to allocate buffers only for unbound columns.  (That's 
> not *quite*
> true.  If the bound buffer is too small, libtds has to allocate enough
> space for the rest of it.  dbdata should work correctly even if dbbind
> allocated too small a buffer.)  
> 

Mmm... a question... does dbdata work if dbbind is used?? If yes you
always have to buffer result...

> We want to make client-allocated buffers available to libtds. 
>  That will
> avoid copying kernel->libtds->client.  
> 

Yes, usually referred as zero-copy :)

bye
  freddy77