Python as a web server?

[Aaron]

WOAH!

Thanks a heap for that rather indepth analysis Alex! Python it is for me
then. I'll start looking at those technologies now and as you say start
simple and go from there.

Cheers
Aaron


"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:94jngf018sb at news1.newsguy.com...
> "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
>
>
>