>I reviewed the Spyce web pages, but did not see any information on
>hosting requirements. This is a big deal to many of us that have shared
>hosting web sites where we cannot control the software installations on
>the server (other than begging :) ).
Excuse the delay. I was working hard on releasing a new version of Spyce,
and finally that was done this morning. The question that you ask is a
good one, but it's difficult for me to answer. Let me try, and perhaps we
can come up with something that you are looking for in the end, and I will
put it online as part of the documentation. The first part of this answer
may be more general than what you were looking for, but please read it to
The problem of specifying a single set of requirements arises from the
fact that Spyce can run in quite a number of configurations, and each
requires something else of the administrator.
Let's start with the basic requirements... First, please read:
Python - You need to have Python installed, and it should be at least
v1.5.2. I highly recommend using Python 2.1 (preferably Python 2.2),
because it supports nested scoping, which helps a lot when writing Spyce
file. However, the engine and the standard modules have been meticulously
written to run properly under v1.5.2.
Apache - I don't really care which version of Apache you run. Some
constraints may be placed on the Apache version by the specific
configuration you wish to run Spyce under. For example, if you want to run
Spyce under mod_python then you will need a mod_python that is compatible
with your version of Apache. The Apache 2.0 modules are only coming out
now, so it might be easier to stick with Apache 1.3.x.
Webserver - In fact, I don't care that you are running under Apache. You
can also run Spyce under other webservers, either as a proxy server, or
via CGI or FastCGI interfaces. I have not tried this myself, but users
have reported success.
Operating System - I have tested Spyce primarily under Linux (the base
development platform), but also extensively under Windows. The versions of
these operating systems do not really matter. I use pretty arcane Posix,
or widely available, system services, and most other functionality is
provided in a portable manner by the standard Python libraries. On the
Linux end, I've had no problems with both 2.2.x and 2.4.x kernels, many
different versions of RedHat, Mandrake and some other distributions. Many
of my users run Spyce under Windows, without additional problems, because
the vast majority of the code is shared. I have also had users that have
reported success on BSD systems, and on MacOS X, though installation must
be performed manually in those cases. The idea is to stay away from
OS-specific features, and actually reduce the number of bugs due to
increased (common) code coverage.
Now starts the "tricky" part... You have a choice how you hookup Spyce to
CGI - The easiest and most portable, but least efficient, way is to use
CGI. In that case, you don't need much more. In fact, you're done.
However, note that this alternative is slow. Its throughput is between one
and five requests per second on a decent machine. The cost comes from
starting a new process, a new Python interpretter, loading the entire
Spyce engine code, and recompiling the requested Spyce file on each
request. That's a lot to do on each request! On the other hand, it's easy
and many people don't need a great degree of performance. One request even
per minute is a high load for a considerable fraction of the web
When you need greater throughput, you can just switch to one of the
following methods, which are roughly equivalent. Each of them (without
even considering parallelisation through multi-node and multi-processor
setups) can handle hundreds of request per second, and with *much* lower
FastCGI - This method of using Spyce is similar to CGI, except that the
FastCGI protocol is followed, which keeps a Spyce server running between
requests, and reuses it. The Spyce server caches the compiled Spyce files,
and merely performs a function call on each request. This requires the
webserver to know how to do FastCGI. Apache and MS IIS, as well as many
other webservers, have FastCGI modules/plugins at:
http://www.fastcgi.com/. This is the one additional constraint on your
webserver - to find a FastCGI module.
Proxy - Another convenient way of running Spyce is in webserver mode.
Even though you could, you probably don't want the Spyce webserver running
your entire site for security and performance reasons. I suggest running
it as a second tier server, and proxying to it. This does not place any
additional software constraints, but it does require reconfiguring your
webserver to redirect Spyce requests to the second tier server, and you
may not have the ability to do that in a host scenario. It's really fast
as well, but you might need to implement a watchdog on the Spyce webserver
(standard problem with second-tier servers), because I have not tested its
mod_python - There is a module called mod_python, which allows you to
integrate the Python interpretter right into an Apache child process.
Again, this requires access to the webserver configuration (to ensure that
it is installed). It also constrains you to use Apache, since this is an
Apache module, and you have to find (or compile) mod_python for your
version of Apache. A version for Apache 2.0 was recently released. For
more information about mod_python, please see: http://www.modpython.org/.
These are the three high-performance alternatives for generating dynamic
web content. Another popular use of Spyce is as a generator for static
content (i.e. run Spyce from the command-line, and use it to generate HTML
files) that you put online. The command-line use of Spyce does not place
any additional software constraints.
>So if I have a server where I cannot control the 1) version of Linux, 2)
>version of Apache, 3) version of mod_python, what are my chances of
Very high! Once you have a Python environment serving the web (as you seem
to have), you're done. That's all I need to run Spyce, a vanilla Python
interpretter. Everything else is self-contained. (Side note: Just be
careful NOT to run the Python interpretter with PythonOptimize turned on,
because the Python parser generator that I am using will fail. The
installation instructions discuss this.) As stated earlier, it would be
nice if that mod_python ran a higher version of Python, but anything above
the nearly ubiquitous v1.5.2 will do.
I hope that helps.
All the best,