John,

>Inside the .Net framework, I would use VB. Why? Because from the web forms to the components, it all meshes together. VB was built on that/for that framework. Outside the .Net framework, yes, VFP would be the call.

I think the most important considerations for Web Services should be performance and stability. It's too early yet to tell what the story will be there. Since Web Services are accessed through a URL via SOAP protocols, which can be running on any system anywhere, there's less glue necessary to tie them in. In fact, ASP+ won't even be necessary for serving them up.

>Remember: Inclusio unius est exclusio alterius
>
>This is why I think VFP should be excised from Visual Studio. It is a good tool that can stand on its own. To survive, it needs to get out of the shadow of Visual Studio.

VFP can and does stand on its own, but also gains some benefits from the VS integration. Why should we give up, for example, the ability to step into VFP components in the VS debugger in multi-language solutions? AFAIK, you can still buy it as a separate product, too.

>>No need to take away the data engine for Web Services.
>
>True, but the data engine is all but irrelevant with web services.

(long pause)..... (lower jaw on floor).....

I don't think we're speaking the same language here, John. Based on how I picture it, 99% of Web Services is gonna be all about data. Where the data resides, and how it's massaged and served up into SOAP and XML responses, are issues of physical implementation, and it's at that decision point that VFP's data engine will be a major factor.

VFP-based Web Service solutions will be easy to create and maintain, and will absolutely scream due to the local data engine.

>>Funny, I'm smiling... all the way to the bank ..... :-)
>
>A healthy attitude indeed. It is the one to have..

I recommend it. :-)