>Ale,
>
>>snip<
>
>>BTW, anyone here recall "time sharing"? How the LAN would replace mainframes/dumb terminals? Isn't it funny how the current WebServer/WebBrowser architecture resembles the above so much?
>
>You bet.
>
>At the risk of sending this thread off in an entirely new direction (ok, it's never stopped me before.. <g>) I have a couple of questions...
>
>Presumption #1: The Internet & desktops are nothing more than a huge network.
>
>Presumption #2: The Internet is stateless.
>
>Given those two presumptions, how does that impact the distribution of executables, data updates and 'fixes'?
>
>I'm leaning heavily towards breaking my apps up into smaller, data-driven sub-exes, giving each data record a GUID and distributing data, exes and 'fixes' piecemeal - all data driven.


Interesting that you should lean that way.
I begin my VFP experience writing the biggest app in the Dept of Revenue, the gaming app. The hardware requirements, bloat, slowness, and instability of a DBC with 200+ tables in it caused me to rethink my approach.

That app is now 21 very much smaller, lighter and faster exes. With no DBC the only thing I lose are views, but there are ways around that which are easy to do. Forms are like objects. I don't use the DE but load tables and queries in the init of the form. If I change a form that is used in more than one exe I only have to recompile those exes to update them. And I generally avoid memo fields. Crashing is just a part of the Win OS, but I no longer lose table structures, gain corrupted indexes or views when a crash occurs on a workstation. Maybe with the commodity workstation that is 1.5 GHz with 512MB of RAM the size of the exe won't matter too much, but that utopia will be a while coming in state institutions.