FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2011/5/22 James K. Lowden <jklowden AT freetds.org>:
> http://www.freetds.org/mars.html
>
> A little explanation of what I see as the problems inherent in MARS and
> why it's bad for TDS and FreeTDS, even if it's necessary to maintain an
> ODBC driver compatible with Microsoft's.  I thought it would be better
> to state my case plainly, where it can be evaluated and corrected, than
> to make occasional snide comments as we slouch our way there.  Maybe
> someone will even write a unit test to measure the "MARS tax".
>
> At microsoft.com, the TDS specification is [MS-TDS].pdf and the MARS
> spec is [MC-SMP].pdf.  (Not sure what the "MC" means, nor why the
> brackets are in the filename.)  The URL will surely change, but the
> filename seems stable.
>

It seems I'm the bad guy here :)

Personally I agree with the four points. I'm a technical and I don't
like the idea to implement stuff again. It's not easy to implement a
tcp stack and it works well. MARS introduce incompatibilities (even MS
warns about differences). It's true that MARS are only useful for ODBC
(at least in FreeTDS view), it complicate network stuff and could even
slow down the protocol more than just extra payload. However we are
implementing a protocol client, not the protocol. If somebody would
ask me I personally would have suggested to implement it using other
ways like multiple connection, pooling and fast session cookies to
bind tcp (or whatever protocol) connections to a single server
connection (I think these "light" connections share prepared
statements, cursors and other minor things).

Currently
- I found implementing MARS challenging and I wrote a working code;
- I have a complicated patch to merge;
- time pass and maintaining the patch is expensive;
- it improve proprietary compatibility.

I know there a lot of stuff that seems more important (like sql 2008
type support).

Regards
  Frediano