>>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.

Yes, that part is getting through to me. What isn't yet (and I'm still looking for material to read) is the mechanism (and overhead implied) in invoking several differnt methods of a Web Service hundreds times, how it can be "stateful" for the invoker from call-to-call and things like that.

>
>>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.

OK, I'm glad to hear you say it is incorrect. Do you know a reference I can read that gives more information?

>
>>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.

I want the confidence, Mike. I just have nothing yet to give it to me. I *am* looking for it.
>
>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.

I've been estimating that these kinds of things are possible as well as being good candidates for Web Services. It's the numerous repeated hits for I/O type operations that worry me. It just feels like there would be too much overhead as to slow things down too much.
>
>>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.

The best that I can do is to refer you to the Wish document I have submitted here.

Thanks,

Jim