>Great analysis Erik...
>
>Yea... it appears XML is very flexible. But, for large amounts of data, I wonder how efficient it is then...

I imagine not nearly as efficient as ADO. Too much fluff. But then again, I question any design that has this much data going over the wire. A few dozen records with a few dozen fields each seems to me like all you want to have in most C/S scenarios anyway. For anything larger (homegrown replication, archiving, etc), I would definitely look at something besides XML.


>It is interesting with the SOAP stuff going on now. (http://www.develop.com/soap) It is funny because YAG was doing this stuff at the VFP devcon in San Diego 2 years ago...

Yeah, I've been keeping an eye on this. MS is now on the road to having XML messaging part of the COM standard. Rick S has also come along way with this, he has classes now that let you manipulate a COM object with XML based messagin over HTTP. Pretty slick. (I am dying to find a way to implement this in production).


>With respect to ADO, I am not sure there the two calls come in. Bascially, I can invoke a method that returns a disconnected Recordset. Sure, I have to query the interface, invoke methods and such. But, I need to do the same thing with XML parser.

But you can do it with ANY xml parser, not just msxml. The client needn't have MDAC 2.0 (or whatever the the first version of ADO that supported DRS was). DataChannel has a Java parser, and there are lots of others besides msxml that will do the job.