Python as a web server?

[Alex Martelli]

"Aaron" <a at a.a> wrote in message
news:980242697.576973 at shelley.paradise.net.nz...
> Hi all, I was wanting to dable in writing a very simple online turn based
> game, and was wondering if python could manage the server and client side
of
> things? I'd need database access on the server, and would need to be able
to
> get the client to print text of course, and draw some simple graphics like
> lines, circles, fills, points and the odd image.

Yes, Python might be quite suitable.  It comes with Python-implemented
simple servers (one for just-HTTP, and one for CGI-or-close-to-it), and
it can also easily cooperate with more powerful general purpose servers
in several ways (CGI, Fast-CGI, LRWP [for Xitami], Apache-specific ways,
IIS-specific ways, and more) -- you need not use HTTP, but that has
several advantages if you can, and the 'turn-based game' approach seems
quite suitable for the request-response model underlying HTTP.

Python offers several ways to provide 'database access' -- depending on
your needs, a simple dbm-like (non-relational) DB might suffice (the
Berkeley one is good, for example), you could use Python-coded Gadfly
(for SQL-based relational DB operation), or interface to whatever
'real' relational DBMS you prefer.

You could use a 'thick client' to provide the graphics you require, or
generate it server-side (as, say, PNG's, ideally -- GIF's are also a
possibility, but you may not want to get embroiled in the licensing
requirements for them) -- or use some compromise, such as SVG (the
'Scalable Vector Graphics' standard for the web, see for example:
http://www.w3.org/Graphics/SVG/Overview.htm8
and require that the client be a browser WITH a plug-in or something
to render the SVG parts of the page).  Thin-client solutions (where
the client is just a browser, or, at worst, a browser plus some kind
of plug-in) tend to have deployment advantages if you can live within
their limitations.  But if you go the thick-client route, Python IS
ok for that too -- and, with PIL (the Python Imaging Library) it's
also excellent for generating images on the fly on the server side.

You might also choose to do a client that runs as an applet inside
a browser's JVM (although I would not advise this) -- if you do
choose this, then Jython is a better choice than naked-Java for
your coding (Jython is the Python version that can generate JVM
bytecode that can run together with Java-generated code, etc).

In other words: while there are several architectural possibilities,
Python is just about the best choice for ANY combination of choices
you can make regarding your architecture.


> Could someone tell me if this is possible or should I use something else
> (Like php). If python is the way to go do you have any links on python
> server writing?

PHP would severely limit your choices, I think (no client-side, and
I don't know how it could interface a Berkely DBM, or easily build
server-side images on the fly, etc, etc).  Python seems the ideal
choice.

You'll get an excellent overview of Python technologies for the web at:
http://starbase.neosoft.com/~claird/comp.lang.python/web_python.html.

But it IS about the technologies -- not really about how you design
your server application, how you choose between server-side, client-
side, and compromises such as SVG, and so on.  Those are issues which
do interact with technology-choices, but are really pretty distinct
from them, except in as much as a given technology may constrain the
available architecture-choice and design space.

My personal advice is: start as simple as you possibly can (and STAY
simple as long as you possibly can).  Do a prototype that is strictly
CGI (simplest; you can run it under any HTTP server of your choice!),
build the images on the server side (with PIL), use dbm if you possibly
can (easier than SQL and a relational DB, if your needs are few) --
get such a prototype to a very-bare-functional-minimum stage, and see
if you can't just deploy THAT.  You'll need to add something, and
quite possibly refactor (perhaps heavily) around identified bottlenecks,
but HAVING a prototype will make your further design job MUCH easier --
you can get feedback from non-technically-savvy users, who would not be
able to contribute if you DIDN'T have a running prototype to show them!

Technological sophistication (most of the above-mentioned technology
possibilities) can come in at the 'refactor to eliminate bottlenecks'
stage, *IF* needed.  Starting with an overly-general, complicated,
very sophisticated architecture, catering to superbly generalized
potential that's never really going to be needed, is a prime cause
of ambitious software projects' failures...!-)


Alex