Pythonic way of web-programming

[Ian Bicking]

On Mon, 2003-04-14 at 05:21, Paul Boddie wrote:
> Ian Bicking <ianb at colorstudy.com> wrote in message news:<mailman.1050210449.24337.python-list at python.org>...
> > Using the Twisted CGI code, it would be a quick change to make it
> > dispatch to a thread instead of a process (as with CGI).
> 
> One of the main concerns about making Twisted the "Pythonic standard"
> is that people who demand a non-threaded, non-CGI handler model for
> scalability reasons (and this did come up recently on
> comp.lang.python, so it is a valid concern) are very likely to fall
> outside the resulting audience. Unfortunately, especially given the
> success of mod_python and other process-forking frameworks, that could
> amount to a lot of people.

It seems like Twisted could fork as well...?  Its internal paradigm
(async) doesn't seem like it needs to be reflected in the things that
are built ontop of it.

> > I'm still thinking about the strategy around it, which is why I haven't
> > actually tried implementing it.  As an experiment it's not that
> > interesting to me, but maybe it could be more than that.
> 
> Well, I've been experimenting with implementing a small framework on
> top of WebKit and mod_python (with Zope being another likely
> candidate), and it has to be said that some frameworks share enough
> similarity and do provide enough flexibility to make
> "super-frameworks" possible. Moreover, with developments like POSH...
> 
>   http://poshmodule.sourceforge.net
> 
> ...it might even be possible for such "super-frameworks" to paper over
> the fundamental but desirable differences between the underlying
> frameworks. For example, some people might want a threaded model,
> whilst others might prefer a process-forking model together with
> similarly convenient data sharing semantics.

I'm increasingly drawn towards forking models as well, as they offer
more guarentees about stability, and some potential for using more
operating-system-level security (e.g., when run as root and dropping to
another user when executing a particular page).

Of course they don't port to Windows, which is why Apache 2 is so
wishy-washy about the execution model compared to 1.3.  On an operating
system like Linux, where threads are simulated with processes, I'm not
sure what the real advantage of threads are -- except for the easy data
sharing, which can be a flaw as well (since there's less partitioning). 
Maybe something like POSH would introduce the same problems.

Some partitioning can be achieved in a threading model by running
separate applications as long-running multi-threaded processes (which is
what I'd generally recommend for Webware/WebKit deployments).


Anyway, the particulars of the choice aside, there would be the
possibility of providing alternatives with a common framework ontop. 
I'm a little wary of this, though... my own perception of Webware (which
just happens to be what I'm more aware of) is that the choices provided
didn't pan out like was hoped (though I wasn't around at the point those
basic pieces were being developed).  For instance, there are a bunch of
different "adapters" meant to connect a web server to the application
server, but only a couple are actually useful (mostly mod_webkit and
wkcgi, and I suppose LWRPAdapter if you're using Xitami).  The choice is
a false one -- offering a diversity of options where most are inferior
isn't very helpful.

Even the AppServer in Webware was built with this in mind, with the
threaded option being one among many... but only the threaded option was
ever really developed, and I think it would be just as valid to add more
features to that AppServer as it would be to create an alternate
implementation with different (say forking) behavior.  No, it would be
better, because code wouldn't get as fragmented and the community
wouldn't be as fragmented.

So, choices are good, but only the best choices.  Too many choices is
just confusing. 

> As for the issue of standard APIs, I believe that such APIs really
> only serve a useful purpose as being something to build on that is
> widely agreed upon, recognised and stable; they don't necessarily
> serve the purpose of being something developers really want to write
> to directly. For example, Java Servlets have arguably served as a
> foundation for more high-level toolkits, whereas writing directly to
> the Servlet API is something that the most productive developers
> stopped doing years ago.

I think there's some basis for an API related to web stuff (on several
levels).  We just need to identify those areas that are ripe.

> Paul
> 
> P.S. The Web frameworks shootout paper is most informative and serves
> as an interesting guide as to the most accessible frameworks that
> could be subverted (or "leveraged" depending on your mindset) by such
> "super-frameworks".

Indeed, that has been on my mind too.

  Ian