David,



>Doug,
>
>>I think a lot of the speed issues will start to diminish as people start to do as I suggest. Right now we put little pieces of VFP "out there" but they run in relationship to the base engine that's using resources on the desktop. Move the whole engine to the server itself. Then we'd REALLY have the ability to not care what front end we were using.
>
>But your backend stuff is still running "in relationship" to your lightning-fast UI, and the two still have to communicate with each other over the wire, making your UI not-so-lightning fast or responsive, so I don't see the big difference between that and remote VFP COM automation servers of today that handle lots of the logic and data access back on the server.

Oh, absolutely! However now we wouldn't need to send the data over the wire to be sorted, parsed and what not. All we'd be concerned with would be screen refreshes and keystrokes.

Oh, wait.. We already have this with terminal services. <g>

>
>You're not suggesting that every action on the UI make a call to the backend, are you? That's somewhat the possibility with Web Forms, which carries a caution about making too many round-trips to the server in response to user actions moving from control to control.

Well, to me I see no real "solution" here. Just a bunch of tradeoffs. The question seems to me to be "Which of these tradeopffs brings benefit bith to Microsoft and to users and developers?" My poin is that this isn't very easy to pull off.

I still think that a rewrite of VFP in assembly or inclusion of massive numbers of assembly routines would be the best option.

If I'm uderstanding the gereral gist of our discussion it's all about speed, wouldn't you say? We're just speculating on how best to boost performance.


Best,

DD


PS - BTW, I've really enjoyed this. Thanks!!