April 2012 - web-devel

Question about the composing order of conduit combination operations
by Hiromi ISHII 05 Apr '12

05 Apr '12

Hi, I'm implementing a tiny SMTP server using conduit-0.4.0 and network-conduit-0.4.0. I wrote code like below: > smtpServer src sink = do > LC.sourceList [ renderReply $ SMTPReply 220 (Just "localhost") ["hello"]] $$ sink > src $$ C.sequence (sinkParser smtpCommand) > =$ LC.map (BS.pack . show) > =$ sink Here is the complete (and slightly different) code: https://github.com/konn/haskell-smtp/blob/master/smtp-server/Network/SMTP/S… (You know, this server is not actually an smtp server; just echoing client's input for now.) I ran this program and communicated using telnet. I expected the access log like below (S means server, C means client; new-lines are CRLF) : > S: 220 localhost hello > C: EHLO another.example.com > S: EHLO "another.example.com" > C: MAIL FROM:<Postmaster(a)example.com> > S: MAIL (Path [] (Mailbox {mbLocalPart = "Postmaster", mbDomain = "example.com"})) [] > C: RCPT TO:<foo(a)example.com> > S: RCPT (Path [] (Mailbox {mbLocalPart = "foo", mbDomain = "example.com"})) [] > C: DATA > C: hoge > C: fuga > C: oooo > C: . > S: DATA "hoge\r\nfuga\r\noooo" > C: QUIT > S: QUIT But I got: > S: 220 localhost hello > C: EHLO another.example.com > C: MAIL FROM:<Postmaster(a)example.com> > C: RCPT TO:<foo(a)example.com> > S: EHLO "another.example.com" > C: DATA > S: MAIL (Path [] (Mailbox {mbLocalPart = "Postmaster", mbDomain = "example.com"})) [] > C: hoge > C: fuga > C: oooo > C: . > C: QUIT > S: RCPT (Path [] (Mailbox {mbLocalPart = "foo", mbDomain = "example.com"})) [] It seems that conduit produces a new SMTPCommand after reading another new command, and processes and convert it into SMTPReply much father later. By the way, I rewrote the program above just like below and everythings seems to be good: > smtpServer src sink = do > LC.sourceList [ renderReply $ SMTPReply 220 (Just "localhost") ["hello"]] $$ sink > src $= C.sequence (sinkParser smtpCommand) > $= LC.map (BS.pack . show) > $$ sink If Conduits, Sinks and Sources are the same sings in conduit-0.4, why these two codes above behaves differently? To summarize, my questions are divided into three: 1. Why the first one doesn't work as I expected? 2. Why the second one works well? 3. Is this difference intended? If so, what are the difference of semantics of ($=), (=$), ($$), (=$=) and their composition? -- Hiromi ISHII konn.jinro(a)gmail.com

2 1

Yesod 1.0 Release Candidate
by Michael Snoyman 05 Apr '12

05 Apr '12

Hi everyone, I'd like to announce the availability of the Yesod 1.0 release candidate. The code is available on Hackage now, so you should be able to install with a simple `cabal update && cabal install yesod` to get up-and-running. If you've been installing from Github or Yackage, you'll probably have the smoothest ride by wiping out your ~/.ghc and ~/.cabal/packages/cabal-src folders, and disabling Yackage as a remote repo in ~/.cabal/config. We're setting a release date of next Monday, April 9. That's when we'll be posting an official release announcement and releasing a new version of yesod-platform. At this point, the code is well tested and usable (in fact, it *is* in production use on multiple sites), but we wanted to give everyone one last chance to hammer away at the code. One of the goals with this release is to try to start pushing Haskell and Yesod to the masses (i.e., we're going to fail to avoid success at all costs). We're going to be trying to demonstrate the advantages Haskell provides over other solutions out there. I think this is the kind of effort that we can all work on together as a community. If anyone's interested in helping out with promoting, please be in touch. Michael

1 0

wai and conduit 0.4 for proxy
by Kazu Yamamoto 04 Apr '12

04 Apr '12

Hello, I'm trying to catch up conduit 0.4. To pass requestBody of Request to ResponseSource of Response, we need to convert types as follows: Source (ResourceT IO) ByteString -> Source (ResourceT IO) (Flush Builder) The way which I could find is: src $= CL.map (Chunk . byteStringToBuilder) Is this a right way? Or, is there another proper way? Cheers, --Kazu

2 2

ANN: acme-http
by Jeremy Shaw 01 Apr '12

01 Apr '12

Hello, As we all know, the true measure of performance for a web server is the classic PONG test. And, so the Happstack team is pleased to announce the release of the new acme-http server! hackage: http://hackage.haskell.org/package/acme-http source: http://patch-tag.com/r/stepcut/acme-http When testing on my laptop with +RTS -N4 using the classic PONG test: $ httperf --hog -v --server 127.0.0.1 --port 8000 --uri / --num-conns=1000 --num-calls=1000 --burst-length=20 --rate=1000 acme-http delivered 221,693.0 req/s, making it the fastest Haskell web server on the planet. By comparison, warp delivered 51,346.6 req/s on this machine. The secret to acme-http's success is that it large avoids doing anything not required to win the PONG benchmark. It does not support timeouts, it does not check quotas, it assumes the client is HTTP 1.1, it does not catch exceptions, and it responds to every single request with PONG. The goal of acme-http is two fold: 1. determine the upper-bound on Haskell web-server performance 2. push that upper bound even higher In regards to #1, we have now established the current upper limit at 221,693.0 req/s. In regards to #2, I believe acme-http will be useful as a place to investigate performance bottlenecks. It is very small, only 250 lines of code or so. And many of those lines deal with pretty-printing, and other non-performance related tasks. Additionally, it works in the plain IO monad. It does not use conduits, enumerators, pipes, or even lazy IO. As, a result, it should be very easy to understand, profile, and benchmark. In providing such a simple environment and avoiding as much extra work as possible we should be able to more easily answer questions like "Why is so much RAM required?", "What is limiting the number of connections per second", etc. As we address these issues in acme-http, we can hopefully bring solutions back to practical frameworks, or to the underlying GHC implementation itself. If performance tuning is your thing, I invite you to check out acme-http and see if you can raise the limit even higher! - jeremy

2 2