Mega Code Archive

Forget developing CGI Web Applications

Title: Forget developing CGI Web Applications Question: The received wisdom seems to be to develop web appplications as CGIs. and then convert to ISAPI for production. I believe this is wrong. Answer: When I went on a training course to learn how to develop web-based systems with Delphi, we were taught and encouraged to develop a CGI system (i.e. running off an .exe file), and then near the end told how to convert it to an ISAPI (i.e. running off a .dll). This seems to be the accepted way of proceeding in many circles. I have also noticed many questions along the lines of How do I convert from a CGI application to an ISAPI one? It seems to me that the underlying assumption is wrong. I would argue strongly that if you are going to develop a system that runs as an ISAPI in a production situation, then you should develop it as an ISAPI system from the beginning. Furthermore, given that any web-based system is going to run much faster from a .dll than an .exe, the sooner we forget the idea of CGI systems, the better. Essentially, my advice is based on my experience of developing a Contacts Intranet system over the last 6 months. I started developing it as a CGI because that seemed to be the thing to do. I have now abandoned that route, and do all my development as an ISAPI. Why? Well these are some of the things I have come across: 1. Things are initialised (or rather they arent) very differently in an ISAPI system. This is because whereas each user picks up a new copy of the .exe, the .dll is shared, with just one copy running in the memory of the server. The consequence is that sloppy coding that you can get away with in CGI is quickly exposed in ISAPI. I found that in a multi-user demonstration, one user was picking up data just updated from another user, with the results that contact persons were attached to the wrong addresses. 2. Data access is very different. In a CGI you can get away with writing cached updates. These do not work in an ISAPI system. I learnt the hard way. All my SQL INSERT and UPDATE statements had to be rewritten in the code. One consequence of this is that they all run very fast. 3. There are other ways, I am sure, in which code operates differently in the different environments (e,g. SQL.Clear), but frankly I dont think they need enumerating to prove the point. 4. CGI applications quickly seize up in a multi-user environment. I discovered this in my first hands-on demonstration to a department in the organisation (only 4 users!). This was using MS SQL Server 7.0 database. A user I have recently been in contact with had a problem with other databases: Whenever two users access my web app at the same time, the BDE locks up and the only cure is to re-boot the server. I am using Paradox tables now, but the same thing happened with DBase tables. He converted to ISAPI, and his locking problems disappeared. Since I have been developing and running as ISAPI, I have had no locking problems. Also the speed of the system improved significantly. So why bother developing a CGI in the first place? The received wisdom seems to be that ISAPIs are much harder to develop in than CGIs. Notably, the reasoning is that recompiling is much harder, and that if you are developing an ISAPI system, you have to keep downing the web server. In my experience this is just not the case. I am using IIS, and all I have to do before recompiling is stop and start the World Wide Web Publishing Service. This only takes a few seconds on the test web server. I run the production system on one web server, and the test system on a different web server. When I want to put out a new version into production, all I have to do is make sure the application is pointing at the live database, change a couple of constants in the program which point to the live web server rather than the test web server, and then (using ProjectOptions) make sure I compile to the correct web server. So, my advice is: "Give CGI the heave-ho!"