[web-devel] RFC: A standardized interface between web servers
and applications or frameworks (ala WSGI)
s.clover at gmail.com
Sun Apr 13 22:43:33 EDT 2008
In a sense, the CGIT interface provided by Network.CGI already is a
sort of halfway implementation of what we're discussing, no?
I'd be interested in approaching this from the other way --
specifying exactly what CGIT doesn't provide and therefore what folks
want to see. As far as I can tell, the main issue with CGIT is that
it doesn't handle streaming/resource issues very well.
The main innovation I see provided here is the enumerator interface,
which is a very nice and flexible approach to I/O and provides a way
to handle comet cleanly to boot. Since the application type as
proposed is Env -> IO (Code, Headers, ResponseEnumerator), what we're
really getting is almost an equiv. (modulo enumerators) of unwrapping
CGIT IO CGIResponse with a run function. So what we lose is the
ability for all our nicely named record accessors and functions to be
shared across frameworks -- i.e. the flexibility a monad transformer
*does* provide. So my question is if we can somehow preserve that
with an appropriate typeclass. I'd ideally like to see this
engineered in two parts -- a "cgit-like" typeclass interface that
allows access to the environment but is agnostic as to response type,
so that comet-style and other apps that take special advantage of
enumerators can be built on top of it as well as apps that simply
perform lazy writes; and the lower-level enumerator interface. This
ideally would let the higher-level interface be built over any stack
at all (i.e. STM-based as well, or even a pure stack), while the
lower level interface that calls it is some glue of the given
constant type in the IO monad. This would be of great help to hvac.
There's also the fact that this could be designed ground-up with
greater bytestring use, but that doesn't seem immense to me.
Outside of this, I'm not quite sure what else CGIT lacks. I'm with
Chris Smith's arguments as to the headers question, and it seems to
me that dicts are best done using MVar-style primitives.
I'm a bit at sea as to why the queryString is here just represented
as a bytestring -- is it seriously an issue that some apps may want
to use it other than in the standard parsed way? Is the idea here
that lib functions would fill in and be shared among frameworks? On
the other hand, seperating GET and POST vars is a good idea, and its
a shame that CGIT doesn't allow this. The openness here seems in part
based on the desire to keep different forms of file upload handling
available. However, the work that oleg did with regards to CGI also
seems promising -- i.e., rather than using an enumerator, simply
taking advantage of laziness to unpack the input stream into a lazy
On Apr 13, 2008, at 7:59 AM, Johan Tibell wrote:
> Good day hackers,
> The Python community have been successful in standardizing an
> interface between web server and applications or frameworks resulting
> in users having more control over their web stack by being able to
> pick frameworks independently from web servers, and vice versa. I
> propose we try to do the same for Haskell. I've written half a draft
> for a Haskell version of Python's PEP 333 . If you're interested in
> taking part in this effort please read through the Python spec first
> (as it is way more complete and you can understand this proposal
> better by reading it, I've skipped some important issues in my first
> draft) and then go read the Haskell spec . I'm particularly
> interesting in feedback regarding:
> * Doing in this way won't work as it violates HTTP/CGI spec part X, Y
> and Z (the Python spec takes lots of things from the CGI spec
> including naming and semantics).
> * My server/framework could never provide/be run under this interface.
> * This interface has bad performance by design.
> * Using a different set of data types would work better.
> The spec needs to be extended to cover all the corners of HTTP. Some
> parts need to be motivated better. It is easier for me to motivate
> things if people would tell me what parts are badly motivated.
> Note: I'm open to a complete rewrite if needed. I'm not wedded to the
> current design and/or wording. In fact parts of the wording is
> borrowed from the Python spec. The parts with bad grammar are all
> 1. http://www.python.org/dev/peps/pep-0333/
> 2. http://www.haskell.org/haskellwiki/WebApplicationInterface
> -- Johan
> web-devel mailing list
> web-devel at haskell.org
More information about the Libraries