>I think one would be the easiest. It would probably be pretty plug and play if you wrote a cursor class that got the data over the internet from the WC back end.

That works well - actually just worked on a project where we did just that. A data class can be loaded based on whether the app runs locally or over the Web and data is pulled via XML down to the client (there are also other non VFP clients).

>For 2, what I can think would be the simplest way would be to write the VFE ap normally and then create an EXE with all the business and data layers and a seperate one with the UI... the BizObj loaders would load the BizObj COM object with WC's HTTPCom class. Main problem here is that VFE is statefull, so it wouldn't scale very well.

wwHTTPCOM only supports stateless access to objects, so you can't set properties - only make single method calls and it can't return object results. However it can return XML which can be persisted objects created with wwXML - this tends to be the approach I take nowadays. Most objects of mine have flags that can be set and the flag determines how data is returned. If the client is VFP an object comes back. If the client is over the Web XML is returned.

I don't know if this approach will work with VFE - object state can't be managed over the HTTP connection very well. The better approach is to do all the processing on the server and then just return the data back to the client rather than trying to do data processing on the client.

The client uses data rather than processing it...