Index: Doc/howto/webservers.rst =================================================================== --- Doc/howto/webservers.rst (revision 79486) +++ Doc/howto/webservers.rst (working copy) @@ -180,7 +180,7 @@ CGI script. Check the configuration of your web server, maybe there is some mistake. * The path to the interpreter in the shebang (``#!/usr/bin/env python``) must be - currect. This line calls ``/usr/bin/env`` to find Python, but it'll fail if + correct. This line calls ``/usr/bin/env`` to find Python, but it'll fail if there is no ``/usr/bin/env``. If you know where your Python is installed, you can also use that path. The commands ``whereis python`` and ``type -p python`` might also help to find where it is installed. Once this is known, @@ -208,12 +208,12 @@ The Python equivalent of that is a template engine. mod_python itself is much more powerful and gives more access to Apache internals. It can emulate CGI, it can work an a "Python Server Pages" mode similar to JSP which is "HTML -intermangled with Python" and it has a "Publisher" which destignates one file to +intermingled with Python" and it has a "Publisher" which designates one file to accept all requests and decide on what to do then. But mod_python has some problems. Unlike the PHP interpreter the Python interpreter uses caching when executing files, so when changing a file the whole -web server needs to be re-started to update. Another problem ist the basic +web server needs to be re-started to update. Another problem is the basic concept -- Apache starts some child processes to handle the requests and unfortunately every child process needs to load the whole Python interpreter even if it does not use it. This makes the whole web server slower. Another @@ -310,14 +310,13 @@ -------- `mod_wsgi `_ is an attempt to get rid of the low level -gateways. As FastCGI, SCGI, mod_python are mostly used to deploy WSGI -applications anyway, mod_wsgi was started to directly embed WSGI aplications -into the Apache web server. The benefit from this approach is that WSGI -applications can be deployed much easier as is is specially designed to host -WSGI applications -- unlike the other low level methods which have glue code to -host WSGI applications (like flup which was mentioned before). The downside is -that mod_wsgi is limited to the Apache web server, other servers would need -their own implementations of mod_wsgi. +gateways. Given that FastCGI, SCGI, and mod_python are mostly used to deploy +WSGI applications anyway, mod_wsgi was started to directly embed WSGI aplications +into the Apache web server. mod_wsgi is specifically designed to host WSGI +applications, and therefore makes their deployment much easier compared to the +other low level methods that need glue code. The downside is that mod_wsgi is +limited to the Apache web server, other servers would need their own +implementations of mod_wsgi. It supports two modes: the embedded mode in which it integrates with the Apache process and the daemon mode which is more FastCGI-like. Contrary to FastCGI, @@ -353,7 +352,7 @@ For example, instead of writing your own session management (to identify a user in subsequent requests, as HTTP does not maintain state, so it does now know that the requests belong to the same user) you can just take one middleware, -plug it in and you can rely an already existing functionality. The same thing +plug it in and you can rely on an already existing functionality. The same thing is compression -- say you want to compress your HTML using gzip, to save your server's bandwidth. So you only need to plug-in a middleware and you're done. Authentication is also a problem easily solved using a middleware. @@ -488,16 +487,16 @@ `framework`_. Some of these are using a plain-text programming language which is very easy to learn as it is quite limited while others use XML so the template output is always guaranteed to be valid XML. Some `frameworks`_ ship -their own template engine or recommend one particular. If one is not yet sure, -using these is a good idea. +their own template engine or recommend one in particular. If one is not yet +sure, using these is a good idea. .. note:: While Python has quite a lot of different template engines it usually does not make sense to use a homebrewed template system. The time needed to - evaluate all templating systems is not really worth it, better invest the - time in looking through the most popular ones. Some frameworks have their - own template engine or have a recommentation for one. It's wise to use + evaluate all templating systems is not really worth it and might be better + spent looking through the most popular ones. Some frameworks have their + own template engine or have a recommendation for one. It's wise to use these. Popular template engines include: @@ -545,7 +544,7 @@ The third and least used possibility are so-called object oriented databases. These databases store the *actual objects* instead of the relations that OR-mapping creates between rows in a database. This has the advantage that -nearly all objects can be saven in a straightforward way, unlike in relational +nearly all objects can be saved in a straightforward way, unlike in relational databases where some objects are very hard to represent with ORMs. `Frameworks`_ often give the users hints on which method to choose, it is @@ -588,11 +587,11 @@ go the minimalistic approach trying to be as flexible as possible leaving the user the freedom to choose what's best for him. -The majority of users is best off with all-inclusive framewors. They bring +The majority of users are best off with all-inclusive framewors. They bring everything along so a user can just jump in and start to code. While they do have some limitations they can fullfill 80% of what one will ever want to perfectly. They consist of various components which are designed to work -together as good as possible. +together as well as possible. The multitude of web frameworks written in Python demonstrates that it is really easy to write one. One of the most well-known web applications written in