>While it does tell me the basics of using such a service and creating such a service for use by others, there was very little regarding how it works and the performance implications of such (not that VFP docs should tell me, but I still have to find it).

You can ask us how they work. Its not that hard, you have this program somwhere (VS.NET, or VFP COM, or maybe a Kylix app running on Linux somwhere) and you can call that functionality using HTTP calls, so any client that uses HTTP (PCs, Linux machines, laptops, cell phones, PDAs, Home Stereos...) can pass paramters to this functionality, that runs somewhere else, and get return values. How do you do this in VFP7? Create a class, and run the Web Service builder. Slick.

>My guess for now is that Web Services used to perform significant I/O for a stateful form(s) application is not practical. Is this incorrect?

Yes.

>I agree that there's lots of stuff to implement here. But the VFP Team can handle lots of stuff, as they've demonstrated in the past.

But why? Why sit down and rethink what has taken the industry lots of years and billions upon billions of dollars to come up with?

>I have no confidence, though, that Web Services could handle the load and give acceptable performance.

Then thats your problem.

>I'm talking about existing applications and those to be developed yet in the "traditional" manner.

I have a desktop app that is tradtional as can be. Then I added the OLEPUBLIC keyword to a couple of classes and was able to automate certain parts of my app (Reindex, print a report, reset counters, relieve inventory). Now, I can call these things remotely with Web Services.

>Meanwhile we have a nice wide population of VFP developers who could continue to exploit VFP for more things, and for longer than might otherwise be possible, with a 'server' like component supporting their established coding practises and product knowledge.

If you can, please explain this server more. Maybe it would help or prototype it IN VFP? I just don't understand what you're trying to achieve that can't be done with existing, standard, accepted technologies, including, but not limited to SOAP, WSDL and DCOM.