>>Exactly. XML messaging has been around for a while. I remember discussions related to VFP's weakness as far as building "web-enabled" applications. And all during the times those dicussions were aired and argued, XMLHTTP was sitting there inside our kernels.
>
>This reminds me of a recent project I was involved on where our solution of using VFP for a Web enabled application was being discussed. The other team, really far from here, with several developers, came up with a solution that took about 4 times longer to build and was much slower. We delivered this application in VFP much faster, with mainly one developer and ease of access for maintainance from the team who took it over after and the speed result was much faster than what was being delivered by the other team. As for the cost, we are talking of about a solution under 100k as oppose to over a million for the other team. And, the beauty, when the client requests enhancements, we can respond extremely fast versus to almost impossible from the other team. So, as for arguing, as it has been the case since over 10 years now, those who argue mainly are afraid of VFP and/or simply don't know anything about it.

It also reveals the utility of VFP components on the sever (if the project will allow). VFP can XML message to ASP or JSP. If the project web service allows VFP under foxISAPI or a side-mounted VFP COM - those little VFP features that are so good at transposing DBF (cursors) with XML or ADO seem to offer a very BIG advantage.

I don't know why MS just does not strap those really neat VFP features to it's other back end products. At least then, NET and ASP developers could take advantage. VFP's speedy native (client) data engine in combination with XML messaging seems to offer a lot of advantages. A "big tent" paradigm.