At 07:46 PM 11/21/2006 -0600, Stephen the Cook wrote: > > This is *EXACTLY* why I don't like the idea of dumping desktop apps > > for Web applications when a desktop app would more than suffice. > > (And no, _Stephen, I'm not talking about sites like Amazon or UPS or > > FedEx. <g>) > > >I have to deal with installing an app to 500+ locations around the globe if >this prototype is accepted. How would you deploy an app that far with >desktop lockdowns? Or would you go for a browser based system where you >have rights on the server?
Thread is a bit old but.... For my main client, we estimate somewhere around 10,000+ PCs are using the software we publish (all VFP applications). Confirmed furthest away - Japan. Most interesting place (to me) Madagascar. The systems use a 1-time download/install file. After that it uses FTP to retrieve a 'version' file, check it against a local version file, and download what is necessary. The 'user' does need 'install' rights to initially get the software on their PC, but other than that, they just need read/write/delete... access to the folder where they installed the application (and to their local database folder if applicable). Up until a few years ago, all the systems were being supported by a dual 333MHz Pentium server running Windows NT Server. The resource utilization on that box was, on average, 5-10% all the time. Of course there were peaks, but the box was in no way being taxed. The main reason we got a new box was because we were running out of disk space and the machine was so old they couldn't find hard drives for it. One of the systems was pushing our VFP DB past 20GB and so we decided we wanted some modern drives with a lot of space (now that 20 GB DB is pushing 34 GB and the other systems have steadily grown, so we're gonna need to expand it's disk space soon as well). From what I've observed, it seems the 'web page' stuff is by far the biggest hog of server resources. You'd expect that of course because of the essentially 'dumb terminal' concept of browser-based systems. About the biggest bottleneck in our design is that initial startup when the 'version' file is grabbed. But the file is generally under 3KB, and since it's retrieved via FTP all the overhead/burden of HTTP...etc isn't there. So the only real limitation is the communication bandwidth. And from what I've seen, using the FTP approach is the most efficient way to go. There's also a lot of nice side benefits you get from no going with a browser-based system. For example, allowing users to continue to work with the application in the event of a communication outage, or central server failure, etc. In some cases, that isn't a big deal because the central resource is the 'reason' for the system (e.g. on-line auctions like ebay, or searching for material like on Amazon). But when you need to work independently, like a lot of our systems do, browser-based systems are out of consideration. And of course, any knowledgeable IT person realizes that a web browser is pretty much the riskiest piece of software on a computer (especially Internet Explorer). -Charlie _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
