Hello all, About two years ago, I wrote a web page for one of my projects, using Network.CGI. I chose that over WASH because it had a simple interface and I thought it would be more stable as a result. Now, Bjorn Bringert has replaced the interface with a completely different one. There is a cgi-compat, but it doesn't build with GHC 6.8.2. Does anyone know a quick way to get my web page functioning again? Is there an early version of Network.CGI (with the 'wrapper' interface) that still compiles under GHC 6.8.2? I'm a bit reluctant to convert my code to the new interface, because it will probably change completely again in a year or so, and I'd rather not have to keep revisiting my project and rewriting the web page... Anyway, I am attaching the source file. Thanks in advance, Frederik P.S. Sometimes programmers make a rule of changing the names of things when they change the interface; this makes it possible to keep the old interface alongside the new one, so code which depends on the old interface don't have to change. Is there a reason why the Haskell community does not adopt this practice? It seems that people are always saying that there is a lack of manpower in this community, perhaps that is an excellent reason to make *fewer* incompatible changes, rather than more? -- http://ofb.net/~frederik/
On Mon, 2008-01-21 at 00:14 +0000, Frederik Eaton wrote:
Hello all,
About two years ago, I wrote a web page for one of my projects, using Network.CGI. I chose that over WASH because it had a simple interface and I thought it would be more stable as a result. Now, Bjorn Bringert has replaced the interface with a completely different one. There is a cgi-compat, but it doesn't build with GHC 6.8.2.
You're in luck! It is trivial to get it to build: { hunk ./cgi.cabal 10 -Build-depends: base, network, parsec, mtl, xhtml, fps +Build-depends: base, network, parsec, mtl, xhtml, + bytestring, containers, old-time, old-locale } That's against the current darcs version of the code. I guess it'd be helpful to do that properly so it builds with both ghc-6.6 and 6.8 and get it uploaded to hackage. I'm cc'ing Bjorn.
P.S. Sometimes programmers make a rule of changing the names of things when they change the interface; this makes it possible to keep the old interface alongside the new one, so code which depends on the old interface don't have to change. Is there a reason why the Haskell community does not adopt this practice? It seems that people are always saying that there is a lack of manpower in this community, perhaps that is an excellent reason to make *fewer* incompatible changes, rather than more?
And Bjorn went one better and made a whole package with exactly the same old api. That way there was an easy route for old programs and we don't have to obfuscate the new api by having to avoid using the most obvious names (that were in use in the old api). Duncan
If you need the old "wrapper" function, then use something like this: wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do e <- getInputs a <- lift $ f $ e output $ renderHtml a best regards, Johannes Waldmann.
Dear Johannes, Thanks, that works for me. Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well? Best wishes, Frederik On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote:
If you need the old "wrapper" function, then use something like this:
wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do
e <- getInputs a <- lift $ f $ e output $ renderHtml a
best regards, Johannes Waldmann.
Hi Frederik, (I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.) That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain. The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI. I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs /Björn Frederik Eaton wrote:
Dear Johannes,
Thanks, that works for me.
Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well?
Best wishes,
Frederik
On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote:
If you need the old "wrapper" function, then use something like this:
wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do
e <- getInputs a <- lift $ f $ e output $ renderHtml a
best regards, Johannes Waldmann.
Hi Bjorn, Well, I don't know what the solution is. As I have said, I think it would be best to keep Network.CGI.Compat. That way, users of the old module just have to change the module name, plus they don't have to hack cgi-compat to get it to compile when cgi is already working. A typical project of mine uses 10 or more packages, and something that makes me reluctant to use Haskell is the experience that after a few years I will end up having to maintain separate versions of significant numbers of those packages if I want something I wrote to stay working. Haskell is supposed to be good for writing large projects, but large projects need stable libraries or they become a maintenance nightmare. It's rather worrying to see that people seem to think that if I don't have time to participate actively in the mailing lists or upload stuff to hackage, then my code doesn't exist... Maybe there is a high cost to keeping Network.CGI.Compat in the cgi package, but I don't see any reason other than an aesthetics, which seems like less of a priority than backwards compatibility. Frederik On Tue, Jan 22, 2008 at 05:31:01PM +0100, Björn Bringert wrote:
Hi Frederik,
(I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.)
That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain.
The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI.
I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs
/Björn
Frederik Eaton wrote:
Dear Johannes, Thanks, that works for me. Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well? Best wishes, Frederik On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote:
If you need the old "wrapper" function, then use something like this:
wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do
e <- getInputs a <- lift $ f $ e output $ renderHtml a
best regards, Johannes Waldmann.
Hi Frederik, I agree with your comments about the headaches of Haskell library stability. I made the change because it seemed like the old library had no users. I should put my money where my mouth is, Network.CGI.Compat is now back in the cgi package. /Bjorn On Jan 22, 2008, at 18:28 , Frederik Eaton wrote:
Hi Bjorn,
Well, I don't know what the solution is. As I have said, I think it would be best to keep Network.CGI.Compat. That way, users of the old module just have to change the module name, plus they don't have to hack cgi-compat to get it to compile when cgi is already working.
A typical project of mine uses 10 or more packages, and something that makes me reluctant to use Haskell is the experience that after a few years I will end up having to maintain separate versions of significant numbers of those packages if I want something I wrote to stay working. Haskell is supposed to be good for writing large projects, but large projects need stable libraries or they become a maintenance nightmare. It's rather worrying to see that people seem to think that if I don't have time to participate actively in the mailing lists or upload stuff to hackage, then my code doesn't exist...
Maybe there is a high cost to keeping Network.CGI.Compat in the cgi package, but I don't see any reason other than an aesthetics, which seems like less of a priority than backwards compatibility.
Frederik
On Tue, Jan 22, 2008 at 05:31:01PM +0100, Björn Bringert wrote:
Hi Frederik,
(I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.)
That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain.
The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI.
I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/ Compat.hs
/Björn
Frederik Eaton wrote:
Dear Johannes, Thanks, that works for me. Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well? Best wishes, Frederik On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote:
If you need the old "wrapper" function, then use something like this:
wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do
e <- getInputs a <- lift $ f $ e output $ renderHtml a
best regards, Johannes Waldmann.
Hi Bjorn, Thank you, that is good to hear. Thank you for giving us the better API as well. Frederik On Thu, Jan 24, 2008 at 11:03:58PM +0100, Bjorn Bringert wrote:
Hi Frederik,
I agree with your comments about the headaches of Haskell library stability. I made the change because it seemed like the old library had no users. I should put my money where my mouth is, Network.CGI.Compat is now back in the cgi package.
/Bjorn
On Jan 22, 2008, at 18:28 , Frederik Eaton wrote:
Hi Bjorn,
Well, I don't know what the solution is. As I have said, I think it would be best to keep Network.CGI.Compat. That way, users of the old module just have to change the module name, plus they don't have to hack cgi-compat to get it to compile when cgi is already working.
A typical project of mine uses 10 or more packages, and something that makes me reluctant to use Haskell is the experience that after a few years I will end up having to maintain separate versions of significant numbers of those packages if I want something I wrote to stay working. Haskell is supposed to be good for writing large projects, but large projects need stable libraries or they become a maintenance nightmare. It's rather worrying to see that people seem to think that if I don't have time to participate actively in the mailing lists or upload stuff to hackage, then my code doesn't exist...
Maybe there is a high cost to keeping Network.CGI.Compat in the cgi package, but I don't see any reason other than an aesthetics, which seems like less of a priority than backwards compatibility.
Frederik
On Tue, Jan 22, 2008 at 05:31:01PM +0100, Björn Bringert wrote:
Hi Frederik,
(I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.)
That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain.
The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI.
I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs
/Björn
Frederik Eaton wrote:
Dear Johannes, Thanks, that works for me. Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well? Best wishes, Frederik On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote:
If you need the old "wrapper" function, then use something like this:
wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do
e <- getInputs a <- lift $ f $ e output $ renderHtml a
best regards, Johannes Waldmann.
participants (5)
-
Bjorn Bringert -
Björn Bringert
-
Duncan Coutts -
Frederik Eaton -
Johannes Waldmann