Pythonic way of web-programming

[Ian Bicking]

On Tue, 2003-04-15 at 03:11, Alex Martelli wrote:
> However -- look at the XML situation for contrast.  There IS just such
> a standard (and parts of it ARE in the standard libraries, while others,
> PyXML stuff, integrate as seamlessly as they can with those via some
> import tricks).  AND YET -- you guys have developed and maintain PyRXP,
> which uses substantially different interfaces -- *AND WELL IT DOES*,
> because thanks to the different interfaces (trees of bare tuples, or
> lists as the case may be, rather than intricate objects as in DOM) it
> can save a LOT of memory, and generally zip along much, much faster.
> 
> Aren't there analogies here...?  

There may be compelling differences in some areas.  For instance, a
template that is DOM-like (i.e., externally controlled) vs. a template
that is self-evaluating, like Cheetah.  But among self-evaluating
templates, the interface seems like it should be possible to unify.

There are deep differences and shallow ones.  It would be really nice to
get rid of the shallow ones.

[...]
> > Finally, there's a transport mechanism.  Here one could use
> > CGI, Twisted, Zope, BaseHTTPServer or whatever else.
> 
> Not sure I'd qualify Zope as a "transport" mechanism!-)  Rather
> the choice here is:
> 
>   -- a custom server program coded in Python (BaseHTTPServer and
>      the like, Medusa, Twisted)
> 
>   -- CGI, the only standard ensuring operability with different
>      webservers (maybe fast-CGI might live here too...?)

I don't think FastCGI has much relation to CGI.  I don't entirely
understand FastCGI, but from what I can tell it just sucks -- it's
easier to do the same thing with a simpler socket connection to a
persistent process (as done with SCGI, WebKit adapters, mod_skunkweb,
and no doubt others).  I think FastCGI manages starting that persistent
process on its own, which seems like a nice feature.

>   -- webserver-specific ways to cooperate with existing webservers:
>      LRWP for Xitami, mod_python or mod_webkit or PyApache for
>      Apache, ASP or lower-level interfaces to MS servers, ...

mod_python is another concept entirely (mod_webkit is just one
implementation of a simple protocol that's web-server-neutral)...
mod_python really is something separate, though maybe it could be made
to look like any other forking request.

> Can we find enough commonality among such disparate needs to
> extract out some common interfaces?  In the DB-API case (and in
> the XML one) there were some existing external standards (not
> necessarily well-observed, vide the SQL standard, but still maybe
> better than nothing) as a reference point.  Besides CGI, and
> HTTP itself, what would we build upon here?  Perhaps the Request-
> Response model you mention would suffice for reasonably high
> level interactions, but much of what one can do e.g. with mod_python
> ISN'T "reasonably high level" (or else one would just use
> PyApache for CGI-substition-level tasks...!).

There is a common thread here: HTTP.  It's not that complicated, and the
interface you'd create for an HTTP transaction seems pretty self-evident
-- request and response objects don't have a lot of novelty to them.

There may be funny Apache-specific things you could do with mod_python,
but I think the benefit of those features is easily outweighed by the
potential benefits of some more unification of web programming for
Python... and besides mod_python, most frameworks share a pretty similar
foundation, even though each one phrases it slightly differently.

  Ian