Any users of Network.CGI here? I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html). Here is what I would like to do: - Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages. Any comments, suggestions, or objections? Here is a summary of the features of NewCGI: - Access to CGI parameters (e.g. form input) from both GET and POST requests. - Access to CGI environment variables. - Ability to set arbitrary response headers. - Support for HTTP cookies. - An efficient implementation of multipart/form-data using Data.ByteString. This allows for efficient handling of file uploads. - Wrapper functions for compatibility with the existing Network.CGI module. - A CGI monad transformer. - Basic exception handling and logging. - Low-level run functions that allow using NewCGI programs with protocols other than CGI, for example FastCGI [4]. /Björn [1] http://www.haskell.org/pipermail/libraries/2006-May/005391.html [2] http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/doc/ [3] http://www.cs.chalmers.se/~bringert/darcs/haskell-xhtml/doc/ [4] http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/
Bjorn Bringert wrote:
Any users of Network.CGI here?
I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html).
Here is what I would like to do:
- Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages.
Any comments, suggestions, or objections?
Bjorn - any progress on this? If you do it in the next week, we could get it into GHC 6.6. If not, I still intend to separate out CGI from the network package so that it can be more easily replaced by your version. Cheers, Simon
On Aug 11, 2006, at 5:18 PM, Simon Marlow wrote:
Bjorn Bringert wrote:
Any users of Network.CGI here? I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html). Here is what I would like to do: - Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages. Any comments, suggestions, or objections?
Bjorn - any progress on this? If you do it in the next week, we could get it into GHC 6.6. If not, I still intend to separate out CGI from the network package so that it can be more easily replaced by your version.
Since there haven't been any objections, I plan to go ahead with this early next week. Should I switch versioning scheme for the packages that I add? My existing packages use date-based version numbers, whereas all packages bundled with GHC seem to use a major.minor[.patchlevel] scheme. /Björn
Bjorn Bringert wrote:
On Aug 11, 2006, at 5:18 PM, Simon Marlow wrote:
Bjorn Bringert wrote:
Any users of Network.CGI here? I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html). Here is what I would like to do: - Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages. Any comments, suggestions, or objections?
Bjorn - any progress on this? If you do it in the next week, we could get it into GHC 6.6. If not, I still intend to separate out CGI from the network package so that it can be more easily replaced by your version.
Since there haven't been any objections, I plan to go ahead with this early next week.
Should I switch versioning scheme for the packages that I add? My existing packages use date-based version numbers, whereas all packages bundled with GHC seem to use a major.minor[.patchlevel] scheme.
I've done this now, and added xhtml and cgi to ghc/libraries/default-packages and to SUBDIRS in ghc/libraries/Makefile. I hope I didn't break anything. /Björn
Bjorn Bringert wrote:
On Aug 11, 2006, at 5:18 PM, Simon Marlow wrote:
Bjorn Bringert wrote:
Any users of Network.CGI here? I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html). Here is what I would like to do: - Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages. Any comments, suggestions, or objections?
Bjorn - any progress on this? If you do it in the next week, we could get it into GHC 6.6. If not, I still intend to separate out CGI from the network package so that it can be more easily replaced by your version.
Since there haven't been any objections, I plan to go ahead with this early next week.
Should I switch versioning scheme for the packages that I add? My existing packages use date-based version numbers, whereas all packages bundled with GHC seem to use a major.minor[.patchlevel] scheme.
Your version numbers are ok, the only requirement is that version ordering is defined lexicographically, so a reversed date is fine (2006.8.22). Cheers, Simon
participants (3)
-
Bjorn Bringert -
Björn Bringert
-
Simon Marlow