This article isn’t strictly related to coding, but has a lot to do with it. Instead of looking at coding itself, let’s look at the environment for a change. Most webservers these days use the Apache webserver.This article isn’t strictly related to coding, but has a lot to do with it. Instead of looking at coding itself, let’s look at the environment for a change. Most webservers these days use the Apache webserver. It’s a proven and stable design and can be extensively modified using modules. This is pretty much the standard environment in which most CGI scripts run these days.
Now let’s take a look at something different. A few months ago I stumbled over this small webserver that nobody ever heard of. It’s called Roxen Challenger. It’s written mostly in a script language, but don’t underestimate this! It’s fast, flexible and well, once you realise the full potential, you’ll cream your pants.
I’m in no way promoting this server, but when it comes to a coding environment, there are huge differences. Under Apache, if you need to build dynamic content, e.g. pull images, text, and other things out of a database, you’ll either need PHP or a CGI script to do it for you. This in itself isn’t a bad thing, but it’s overhead still. The Roxen challenger server has built in functions to handle database connections. It also has a PHP like language embedded in the server itself. In combination with CGI scripts, this can be a very flexible solution.
Of course there are other interesting developments out there, such as mod_perl, and totally new ways of having the server communicate with your CGI script, such as over a Unix socket, to create CGI servers.
Always keep in mind that the best environment to work with is the proven one, in this case, that will always be Apache since it’s the most widespread server in use. But realise that one day you might end up having to write a script for NT using IIS, or maybe a script that will run with the Roxen Challenger server, or any of the other dozen webservers available out there.
What it all comes down to is to try and write your scripts as portable as possible, not using any special feature found in just that one
webserver you use, and to always check up on the developments in the webserver field. You never know, tomorrow they might come out with
a webserver written in Perl, or they’ll redefine the CGI standard.
