FreeTDS Development Group

["Medi Montaseri" <medi AT resonate.com>]

Your points regarding defficiencies of SOAP are correct with a bit of
clarification. If you think of SOAP as just a technology to solve
marshalling (or message framing) with a relatively agnostic language
(called XML), then we might indeed have a technology that can be
embraced. The fact that SOAP has been mostly implemented on HTTP (a
stateless Transport) has created a bit of issue, though SOAP can be
implemented on even SMTP, FTP or any transport.

But the deeper issues (as you raised as well) is the concept of a
context (or a session). That is the application layer can benefit from a
sustained connection, giving it a context (who am I talking to, what we
have been talking about, etc, etc). However even this conext problem,
can be solved via a logical session (or context)at the application layer
via a session ID, just like web programmers do. But I agree that when we
make advances in technology, it should simplify things not move the
problem from one place to another.

The other point (you mentioned) and I like is Openness which benefits
open source software. This will happen just as it happened to the top
layer (ie SQL). The bottom layer (wire protocols, etc) will also at some
point converge. 

Sorry for consuming the bandwidth...I just could'nt avoid it on a lazy
Friday....

However, my question still remains, what does TDS API do ? Give me a
fish or show me how to fish... :-)

Cheers
Medi 

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: Thursday, April 19, 2007 8:54 PM
To: FreeTDS Development Group
Subject: Re: [freetds] FreeTDS API basic/newbe question

Hi Michael, 

michael.peppler AT bnpparibas.com wrote:
> Database engines do speak SOAP, or can be made to (eg ASE 12.5.x and 
> 15 can be configured to do so with an add-on feature).

Learn something new every day....

The problem with SOAP, from what I can tell, is that it's both too much
and too little where databases are concerned.  It's stateless, right?
Is there a cancel protocol?  

> However, as a general method of communicating with clients I think the

> overhead would be much too high. The TDS protocol is *much* more 
> compact
> 
> than XML and requires a lot less conversion (data sent in binary)...

I look forward to the day when database clients and servers are as
interchangeable as are web and email servers and clients.  It is a dim
and distant future, I know.  To get there, we need a text-based
protocol, even if it includes an xs:base64Binary encoding option.
(There is no example of a widely implemented free binary protocol,
unless you count NFS, which I don't.)  It certainly won't put the
proprietary/specialized protocols out of business right away, but it
would simplify and standardize database access.  

I personally believe this will a logical outgrowth of the widespread
adoption of free databases.   

Regards, 

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds