Friday, February 2, 2007

WK3 - I have made up 2 CGI programs in my homepage.

Refer to the last week, i promise for the RSS aggregator's release, and now it comes out for your test. Another function is a survey with Cookie. Click here to CGI to have a try. It's just a little tricky. I am not feel content on these, so i would like to get more things on this page. Welcome to concern with my page!

WK3 - Installing your CGI script on a Unix system

Read the documentation for your HTTP server and check with your local system administrator to find the directory where CGI scripts should be installed; usually this is in a directory cgi-bin in the server tree.

Make sure that your script is readable and executable by ``others''; the Unix file mode should be 0755 octal (use "chmod 0755 filename"). Make sure that the first line of the script contains #! starting in column 1 followed by the pathname of the Python interpreter, for instance:

#!/usr/local/bin/python

Make sure the Python interpreter exists and is executable by ``others''.

Make sure that any files your script needs to read or write are readable or writable, respectively, by ``others'' -- their mode should be 0644 for readable and 0666 for writable. This is because, for security reasons, the HTTP server executes your script as user ``nobody'', without any special privileges. It can only read (write, execute) files that everybody can read (write, execute). The current directory at execution time is also different (it is usually the server's cgi-bin directory) and the set of environment variables is also different from what you get when you log in. In particular, don't count on the shell's search path for executables (PATH) or the Python module search path (PYTHONPATH) to be set to anything interesting.

If you need to load modules from a directory which is not on Python's default module search path, you can change the path in your script, before importing other modules. For example:

import sys
sys.path.insert(0, "/usr/home/joe/lib/python")
sys.path.insert(0, "/usr/local/lib/python")


(This way, the directory inserted last will be searched first!)

Reference:

Thursday, February 1, 2007

WK3 - Let me talk about "Pros and Cons of CGI"

There are advantages and disadvantages to writing your Web applications as CGI programs.
I’ll talk about the good stuff first – the advantages of CGI programming.

The main advantage of CGI programming is that it’s ultimate cross-platform technology. It works on Web servers running both Windows and UNIX, and with almost every Web server. So when you write CGI programs, you can be fairly certain that they’ll be portable to whatever environment you’ll want to run them in. The second major advantage of CGI is that it’s language of your choice. There‘s no need to learn a new programming language just to write CGI programs. If you choose a cross-platform language, like Perl, Python, it’s trivial to port your programs from UNIX to Windows, or vice visa.

Another advantage of CGI is that it’s a very simple interface. It’s not necessary to have any special libraries to create a CGI program, or write your programs to use a particular API. Instead, CGI programs rely on the standard UNIX concepts of standard input, standard output and environment variables to communicate with the web server.

Now let’s take a look at the disadvantage of CGI. The single greatest disadvantage of CGI program comes into play when write your programs in a scripting language. Every time a CGI program is requested, the interpreter for the scripting language has to be started, the script has to be evaluated, and then the script has to be executed. The fact that you have to run the Python interpreter every time a Python CGI script is requested is very inefficient. Whether this is a problem depends on how powerful your Web server is, how many requests there are for your CGI scripts, and how long it takes the CGI programs load. Generally speaking, the performance issue does not become a problem unless you run a very high traffic Web site, or you have an antiquated Web server.

People who write their CGI program in a compiled language like C don’t have to deal with this problem, because there’s no extra overhead like that generated by an interpreter. In fact, it was once common to use small, fast-executing CGI programs as a gateway between the Web server and the application server process. That allowed the application server to work with Web servers that they can’t communicate with through a native interface.

The other main complaint about CGI program is that they don’t make things as easy on Web programmers as some other newer Web application platforms. When you write a CGI program, in addition to all of the program logic that creates the functionality you want, you also have to write code to generate the HTML code for the page. Most of today’s popular application servers allow you to embed program logic within a standard HTML page, which can save some work when you write the programs. These application servers are also easier to learn for people who know HTML but don’t know how to program. It is, however, harder to write a structured, well organized programs when you use this type of technology, so the choice really is really one of preference. One isn’t absolutely better than another.