Shameless plug warning.

...

From what I can tell, there are two problems with WASH:

1) Everything must be done the WASH way

2) WASH is mostly broken with GHC 6.4

Let me elaborate a bit on #1.

Let's say I have a CGI interface pre-defined; I take certain parameters from a GET request and do certain things, generating certain headers no the result.

WASH is all centered around generating its own forms, naming its own fields, passing around its own state. It's not at all clear how to handle this myself, as I would with Perl or PHP.

If there is a way, please explain it and I'll be happy :-)

Perhaps you want to have a look at HSP? :-) It doesn't solve all your problems though; it still requires the output to be text/html (or text/xhtml rather), but hopefullly a future incarnation will be more general. Anyway, you can get it from http://www.cs.chalmers.se/~d00nibro/hsp Feedback greatly appreciated. :-) /Niklas

On 2005-06-02, Ferenc Wagner wrote:

Yes, I also mailed upstream and got no response. But I'm using WASH under GHC 6.4 without any problems. Automatic preprocessor invocation is not supported in 6.4, but that style of coding didn't really work out for me anyway.

Can you enlighten us as to how you made that work? I built and installed WashNGo 2.3.1 using the patch at http://article.gmane.org/gmane.comp.lang.haskell.libraries/3160 for GHC 6.4. When I try to build a particular program that uses it, I get this: /usr/local/lib/WASH-CGI-1.4.37/ghc-6-4/import/Fields.hi : Could not find module `ISO8601': it is not a module in the current program, or in any known package. ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): forkM Declaration for zdfReasonISODate{v} Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/.

I'd like to hear more about people using Arrows-minus-arr, as I ran into the same in a project I'm working on for interactive construction of GUI-wrapped functional values & code. - Conal -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jeremy Shaw Sent: Wednesday, June 01, 2005 10:55 AM To: John Goerzen Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] CGI module almost useless Hello, I have done all of those things in WASH. But, don't let that stop you from writing something better :) I think some people started a project to write a CGI interface based on a 'Category' -- where a 'Category' is like an 'Arrow' without the 'pure/arr' function... Jeremy Shaw. At Wed, 1 Jun 2005 17:44:38 +0000 (UTC), John Goerzen wrote:

My apologies if this sounds like a bit of a rant; I know people put

effort into this, but....

The Network.CGI module in fptools (and GHC) is not very useful. I

good think

that it should be removed or re-tooled. Here are the main problems with it:

1. It does not permit custom generation of output headers. Thus the CGI script cannot do things like set cookies, manage HTTP auth, etc.

2. It does not permit generation of anything other than text/html documents. Many CGI scripts are used to manage other types of documents. Notably this makes it incompatible with serving up even basic things like stylesheets and JPEGs.

3. It does not permit the use of any custom design to serve up HTML, forcing *everything* to go through Text.Html. This makes it impossible to do things like serving up HTML files from disk.

4. There is documentation in the code, but it is as comments only, and doesn't show up in the Haddock-generated GHC library reference. (Should be an easy fix)

5. It does not appear to support file uploads in any sane fashion

Is there a better CGI module out there somewhere that I'm missing, or should I just set about writing my own?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

[ Moving this thread slowly to the libraries list... ] Bjorn Bringert wrote:

John Goerzen wrote:

...

My apologies if this sounds like a bit of a rant; I know people put good effort into this, but....

The Network.CGI module in fptools (and GHC) is not very useful. I think that it should be removed or re-tooled. Here are the main problems with it:

1. It does not permit custom generation of output headers. Thus the CGI script cannot do things like set cookies, manage HTTP auth, etc.

2. It does not permit generation of anything other than text/html documents. Many CGI scripts are used to manage other types of documents. Notably this makes it incompatible with serving up even basic things like stylesheets and JPEGs.

3. It does not permit the use of any custom design to serve up HTML, forcing *everything* to go through Text.Html. This makes it impossible to do things like serving up HTML files from disk.

4. There is documentation in the code, but it is as comments only, and doesn't show up in the Haddock-generated GHC library reference. (Should be an easy fix)

5. It does not appear to support file uploads in any sane fashion

Is there a better CGI module out there somewhere that I'm missing, or should I just set about writing my own?

I wrote this module (based on the Network.CGI code) a while ago:

http://www.dtek.chalmers.se/~d00bring/darcs/blob/lib/Network/SimpleCGI.hs

I don't remember what it does really, but I think it solves issues 1,2,3 and some of 4.

Although (among other people) I did some hacking in this module in the remote past, I don't have the time and energy to maintain and/or extend this module anymore. It would be really great if somebody more actively working in this area could take the spec lead here and push the development via discussions here on this library list. John? Björn? A few general design thoughts: * To keep people's mind sane, backwards compatibility with the existing Network.CGI would be a very worthy goal. * Don't use any Haskell language extension available. :-) Currently the module can be used e.g. by Hugs in H98 mode, and keeping it that way would again be something very desirable. Cheers, S.