[web-devel] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

[Sterling Clover]

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  
dictionary.

Regards,
S.

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 [1]. 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 [2]. 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
> mine.
>
> 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
> http://www.haskell.org/mailman/listinfo/web-devel