>>
>>Another aspect would be consultation on future development directions. I'm very interested in the possibility of using a VFP front-end talking to a VFP server module and sending data back and forth with TCP/IP and XML. Since the front-end and server programs have such different jobs to do, it seems like they would each be based on a different framework. A primary design goal would be to enable the client to connect to the server either over a high-speed in-house LAN or via the Web, somewhat seamlessly.
>>
>
> PMFJI - I've got an app. that does exactly this. It's based on both MM's and WebConnect. My MM's app uses the wwIPStuff library to establish it's connection to the server over TCP/IP, the server is running WC under IIS 4. It can respond to the requests from the client app and doesn't care if they're connected via a LAN (which is how I test it during development) or dial-up (which is how it will be deployed for most of their customers). I decided to send the data using Rick's wwEncode/wwDecode methods instead of XML, but that was more for speed than anything else (since I knew for sure both sides are VFP apps). Some of the messaging is XML, though. This is primarily and off-line application that sends in orders and resyncronizes data - but Rick has some neat classes that could handle a "fat client" web app.
>
> Between the stuff that's provided in WC, and in MM, you've got everything you'd need to do something like this.

Paul, please do jump in!

I'm delighted to know that you are doing this. Also pleased to know that MM will work well with WebConnect. The Feltman's have been more visible in their collaboration with Rick Strahl so I wasn't sure about this.

Do you see the point I was making about the server and the client each needing a quite different framework or class set?

Why don't you start a thread under 3rd Party--MM and tell us a little more about this app...

I've heard the phrase "data islands" and it seems to capture an idea that I've had about sending a selection of related data records to the client. Not just the immediate record being updated but related records that the user might want to browse to. The user could navigate around within this set without further network traffic until they performed an update or reached the boundaries of the "data island". Does this make sense to you?

Peter