Re: [Haskell-cafe] CGI module almost useless

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

Sven Panne wrote:
[ 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.
I have cleaned up my CGI module linked to above, added some documentation, and compatibility wrappers to support the current Network.CGI interface. The code is in a darcs repo at: http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/ It fixes 1,2,3 and 4 from John's list, and 1 from Sven's. It relies on some extensions as it uses Control.Monad.State. Here is a very simple example which uses the interface: http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/examples/printinput.hs To the people here who are interested in the CGI module: What do you think of this interface? Could we replace the current Network.CGI with something like this? /Björn

At 23:06 14/06/05 +0200, Bjorn Bringert wrote:
To the people here who are interested in the CGI module: What do you think of this interface? Could we replace the current Network.CGI with something like this?
I am coming partway into this issue, and may be missing some prior art (or something). I think a an easy-to-use CGI module would be cool. Your sample code suggests a nice easy-to-use interface. Even cooler would be if it comes with support to hook into Apache's FastCGI module, or similar optimized invocation from Apache. That might inspire me to do some more work on my nascent SPARQL (RDF query) implementation. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

Graham Klyne wrote:
At 23:06 14/06/05 +0200, Bjorn Bringert wrote:
To the people here who are interested in the CGI module: What do you think of this interface? Could we replace the current Network.CGI with something like this?
I am coming partway into this issue, and may be missing some prior art (or something).
I think a an easy-to-use CGI module would be cool. Your sample code suggests a nice easy-to-use interface. Even cooler would be if it comes with support to hook into Apache's FastCGI module, or similar optimized invocation from Apache. That might inspire me to do some more work on my nascent SPARQL (RDF query) implementation.
Graham, thanks for the suggestion. I went and had a look at FastCGI, and wrote an FFI binding to the fcgiapp C library. You can now use CGI programs with either CGI or FastCGI, using the same interface. My CGI module is in a darcs repo at: http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/ The FastCGI module is at: http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/ To use FastCGI instead of CGI, just import Network.FastCGI instead of Network.CGI (currently Network.NewCGI to avoid conflicts). A simple example with CGI: http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/examples/printinput.hs And with FastCGI: http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/examples/printinpu... /Björn

At 16:04 15/06/05 +0200, Bjorn Bringert wrote:
You can now use CGI programs with either CGI or FastCGI, using the same interface.
This is excellent! Thank you very much! I hope I can have a go at using this really soon -- I have some other commitments immediately, but this is just the kind of tool I would like to deploy simple data manipulation services for which I think Haskell is ideally suited, but didn't previously have the wherewithall to get it accessible on the web. Will this be part of the standard library distribution? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

On 6/15/05, Bjorn Bringert
Graham Klyne wrote:
At 23:06 14/06/05 +0200, Bjorn Bringert wrote:
To the people here who are interested in the CGI module: What do you think of this interface? Could we replace the current Network.CGI with something like this?
I am coming partway into this issue, and may be missing some prior art (or something).
I think a an easy-to-use CGI module would be cool. Your sample code suggests a nice easy-to-use interface. Even cooler would be if it comes with support to hook into Apache's FastCGI module, or similar optimized invocation from Apache. That might inspire me to do some more work on my nascent SPARQL (RDF query) implementation.
Graham, thanks for the suggestion. I went and had a look at FastCGI, and wrote an FFI binding to the fcgiapp C library. You can now use CGI programs with either CGI or FastCGI, using the same interface.
My CGI module is in a darcs repo at: http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/
The FastCGI module is at: http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/
I'm having problems building FastCGI. It uses 'runCGIEnv' which isn't exported from Network.NewCGI. -- Friendly, Lemmih

Lemmih wrote:
On 6/15/05, Bjorn Bringert
wrote: Graham Klyne wrote:
At 23:06 14/06/05 +0200, Bjorn Bringert wrote:
To the people here who are interested in the CGI module: What do you think of this interface? Could we replace the current Network.CGI with something like this?
I am coming partway into this issue, and may be missing some prior art (or something).
I think a an easy-to-use CGI module would be cool. Your sample code suggests a nice easy-to-use interface. Even cooler would be if it comes with support to hook into Apache's FastCGI module, or similar optimized invocation from Apache. That might inspire me to do some more work on my nascent SPARQL (RDF query) implementation.
Graham, thanks for the suggestion. I went and had a look at FastCGI, and wrote an FFI binding to the fcgiapp C library. You can now use CGI programs with either CGI or FastCGI, using the same interface.
My CGI module is in a darcs repo at: http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/
The FastCGI module is at: http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/
I'm having problems building FastCGI. It uses 'runCGIEnv' which isn't exported from Network.NewCGI.
Damn. Sorry. I forgot to push the NewCGI changes needed by FastCGI. Fixed now. There is a problem with FastCGI where Apache gets a broken pipe now and then. I haven't figured it out yet. Network.FastCGI currently also logs a lot of stuff to error_log. So it's not really ready for any use other than experimentation yet. /Björn
participants (5)
-
Bjorn Bringert
-
Graham Klyne
-
Graham Klyne
-
Lemmih
-
Sven Panne