FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: February 11, 2003 4:54 AM
> > 
> > Oh, we're on different wavelengths here.  I had in mind a 
> > future configure
> > switch:
> > 
> > --with-abi= [sybase|microsoft|freetds] #default freetds
> > 
> > superseding --with-sybase-compat.  
> 
> We have two compatibily now. MS and Sybase. MS is widely 
> accepted on windows
> while Sybase on unices. So why don't we provide default MS binary
> compatibily for windows and Sybase one for unices??

Binary compatibility means exposing and exporting precisely the same
interface to the linker as do the vendors' libraries.  It's not always a
good thing even when it's possible.  For instance, both vendors export
"dbopen()", but that name is used by other database libraries (e.g. dbm).
Binary compatibility would prevent an application from using both libraries.


As to what the default should be (supposing we ever got far enough along to
really worry about the question), I think binary compatibility is a
specialized use of FreeTDS, and a black art besides.  That's why I suggest
we export our own interface by default.  

> For example provide (under unices) two functions: dbdatecrack and
> dbdatecrack_ms. Defining MSDBLIB in source file activate a #define
> dbdatecrack dbdatecrack_ms so programs compiled in such way 
> use Microsoft behaviour while other use Sybase behaviour...

That would achieve source compatibility.  Microsoft's db-lib doesn't export
"dbdatecrack_ms()", though, so that plan would defeat binary compatibility.


I think everyone's first concern is to have as complete and reliable an
implementation as possible, adhering in all respects to a source-compatible
API.  Binary compatibility might be feasible, at the cost of some complexity
and some loss of flexibility.  As we make choices, it's good to keep all
these objectives in mind.  

Agreed?

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.