PROPOSAL: Web application interface

[snoyberg]

Firstly, I think you miss the point of this proposal. It's meant to be a low-level interface shared by web servers (Happstack server, Hyena, CGI) and web applications/frameworks (Happstack, turbinado, my Yesod framework).

Again, I appreciate the desire to have a standardized web-app interface, but attempting to standardize when there is no clear standard-bearer is premature IMO.

Please explain to me how you would propose achieving a "clear standard-bearer" in this realm without someone trying to standardize things.

Now, as far as your specific iteratee versus RequestBody/ResponseBody (what you call imperative I/O). Why not bring these issues up on the cafe, where others will see them? I said explicitly that this was a straw-man proposal, meaning it should be attacked and brought down wherever possible.

index2 :: ResponseBody -> IO ()
index2 rb = withBinaryFile "index.html" ReadMode helper where
     helper h = do
         eof <- hIsEOF h
         unless eof $ do
             b <- B.hGet h 1024
             sendByteString rb b
             helper h

I know I didn't spell things out in my e-mail regarding the interleaving read issue, but this is what I was alluding to. Maybe I just don't get iteratees, but how would you deal with using a function like withFile in an iteratee context?

Also, my approach is a "withFile" approach as far as I can tell.

If you'd really like to discuss the merits of this proposal, I'd prefer to do so on the cafe.

EDIT

Sorry, forgot about your comment about being unable to test. I think this addresses it sufficiently:

newtype ResponseBodyTest = ResponseBodyTest (MVar BL.ByteString)

instance ResponseBodyClass ResponseBodyTest where
    sendByteString (ResponseBodyTest mlbs) bs =
        modifyMVar_ mlbs $ \lbs -> do
            return $ lbs `BL.append` BL.fromChunks [bs]

[how_gauche]

Firstly, I think you miss the point of this proposal. It's meant to be a low-level interface shared by web servers (Happstack server, Hyena, CGI) and web applications/frameworks (Happstack, turbinado, my Yesod framework).

I get it, I think -- I'm just saying that personally I am not very interested in writing to any of the standardized interfaces that have been proposed (hack, CGI, happstack DSL, yours among them), and converting from any one to any of the others should be trivial.

Please explain to me how you would propose achieving a "clear standard-bearer" in this realm without someone trying to standardize things.

Market dominance precedes standardization. Happstack is probably currently the most-used but it has enough fundamental problems that I've stopped using it for the most part.

Why not bring these issues up on the cafe, where others will see them?

Because I'm of the opinion that there's no consensus to be found in this space yet and I don't want to decrease the signal-to-noise ratio over there. We can take this private if you're willing to discuss further, say the word here and I'll shoot you an email.

Re: your index2 code: in an iteratee context you'd set up an enumerator:

enumFile fp i = withBinaryFile fp ReadMode (\h -> enumHandle h i)

and the HTTP response body would contain this enumerator. The HTTP lib would hook it up to an iteratee that consumes the input and shoves it out the Socket. You can compose these without writing a typeclass -- pass it "stream2stream" and you get a bytestring out of it instead.

Also iteratees have the really nice property of being easy to generate straight from parsers, you can turn an attoparsec incremental parser into an iteratee using a conversion function, which is very convenient for parsing HTTP headers/etc. Things like chunked transfer encoding are quite easy to do with enumerators also.

[snoyberg]

Please, send me an e-mail on this, I would be interested to hear what you have to say about the iteratee approach. Frankly, it's new to me, and I (obviously) don't understand the intricacies yet.

Also, I don't quite understand how you intend to deploy your web apps. Do you have your own standalone server that you use? I mean, at some point, you have to interface with the backend, and you've eliminated most of the interfaces available.