Hi David,


>Doug,
>
>>The problem I see with the splitting of things apart is that you either have to give folks the ability to put anything in the "mix" or nothing... Great idea but I don't think it'd work.
>
>The concept of limiting commands for a specific compile option seems to have worked pretty well with MTDLL, with minor exceptions like no printing. :-)

Well, you still have the issue of the interrelationship of all of VFP's components. Without any regard whatsoever for the merits of either/any side of the "should we" question I think the simple technical issues of the exponential nature of the internal inter-relationship of each of VFP's components would prohibit a cost effective solution here. I also think the tradeoffs would not be a wise business case.

>
>>The other option I already mentioned would be to put all the code response logic into a COM or COM+ enabled object. Having 5-6MB of code running on a server isn't a real big deal anymore and if the code that actually did the work was on the same central machine that had the data I could see a LOT of performance gains as you have eliminated the wire between your desktop and the server.
>
>Sounds like remote COM automation servers to me, which we have now.

Right, but turn the VFP engine into a COM+ object. Think in terms of each "piece" of any given software package as a COM+ object is where I'd go. Put your dang menu COM+ object on a server, put your report COM+ object on a server, put VFP's command response engine as a COM+ object on your server, etc..

In my mind, placing VFP this way on the SAME SERVER as the data would give me a GREAT speed increase as the data is local to the engine. Right now, remember, we load that engine on the desktop... We've been doing this way since Day One and what I'm suggesting is that we take a whole new, fresh approach to where we want to go. In my scenario we'd load a lightning fast UI on the desktop, use a common engine plus common objects ON THE SERVER where they do not have to contend with network traffic & collisions and where the data engine is local to the data. Kind of like a SQL version of FoxPro. This would give us FoxPro folk a way to take the next logical step to SQL, if we needed to so do. It would also place us in the position of being able to be a great back end data engine for all those VB weenies <g> whose only real choice right now would be SQL or some other ODBC based product when they might want to benefit from VFP's very robust and rich development environment. It also helps us to work together and provides some interesting career path options. Well, rather than trying to get everyone to the desktop why don't we move VFP to the Server? The last time you checked the processor usage of your server what was the number? 10%? 4%? 20%?

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.

Best,

DD