[Web-SIG] Shameless self promotion, and serious question.

[Paul Boddie]

A.M. Kuchling [mailto:amk at amk.ca] wrote:
> 
> On Wed, Mar 17, 2004 at 06:15:38PM +0100, Paul Boddie wrote:
> > support to be rather irritating - FieldStorage is just one part of that -
> > and sometimes one wonders if it's really possible to make a sane layer of
> > functionality without undoing the dubious design decisions of various
> > frameworks and then having to reimplement that sanity, afresh, on top.
> 
> I suspect that most web frameworks will bypass the 'cgi' module as much as
> possible; it's too messy to deal with and too difficult to clean up.

Yes, I doubt that most people actually use the FieldStorage class to the
extent of its design; that is, the way that objects of that class can
presumably reside in hierarchies, given the MIME-based nature of HTTP
message bodies. On that front, it's important to distinguish between
"fields" which come from the URL and those which come from some part of the
message body; there have been various discussions about "merging GET and
POST parameters", but the different frameworks are pretty inconsistent on
this. Another disturbing aspect of FieldStorage is the usage of temporary
files and other seemingly "early Web Age" techniques.

> I'm puzzled by the WebStack package.  Why implement a layer of sanity on top
> of various dubious frameworks, instead of just implementing that layer of
> sanity directly?  But then it's just another framework, and it becomes
> apparent that definitions of sanity differ.

Well, when peeling back framework behaviour which seems errant, and
attempting to support BaseHTTPRequestHandler as a first-class framework, one
does almost start to implement one's own "sane" framework. Anyway, my
motivations should be clearly stated in the README.txt file, but my belief
was that most frameworks do most things in mostly the right way, and by
making use of those mechanisms and exposing them to applications in a
unified fashion, one doesn't have to care about which framework one is going
to be deploying on. Some people are wedded to the choice of certain
frameworks, either for practical or for ideological reasons, but that
doesn't mean that the applications available have to be divided up into
"exclusive", fragmented groups which then have to be ported between
frameworks as the need arises.

A side effect of this, given various oversights in various frameworks, is
that a library of knowledge and techniques can be built up both around each
framework and around the implementation of Web/HTTP mechanisms in general.
It's a bit like a code version of the Web Frameworks Overview but with stuff
you can play with. But really, I just want to be able to deploy things on
different frameworks, hopefully providing things like better URL-to-resource
mapping within applications - an area which often seems incoherent or just
poorly supported within today's frameworks. Whether it's possible to work
around every limitation at a higher level than the underlying framework
seems doubtful, but it's arguably better than slowly drifting towards an
agreement over a vague API specification that none of the framework
developers are interested in implementing anyway.

Paul