- web-devel - Haskell.org

WAI/Warp 1.1 released
by Michael Snoyman 05 Feb '12

05 Feb '12

Hi all, I've just released WAI and Warp 1.1, which is a minor (but breaking) change to 1.0. The differences are: * We now use a Source instead of a BufferedSource for requestBody * Support for conduit 0.2 This release includes updates to the entire WAI family of packages. As usual, there are various bug fixes/performance enhancements throughout the code base. Michael

2 4

Abstracting permissions with Yesod
by Felipe Almeida Lessa 03 Feb '12

03 Feb '12

Hello, everyone! I'm going to try creating a blog and my first post is dedicated to how I am writing my isAuthorized function: http://blog.felipe.lessa.nom.br/?p=7 I'd be thrilled if you could tell me if you like the idea! Something similar could be done on Yesod 0.10, either on yesod-core or on the scaffold. I didn't try writing some generic code yet because I'd like to gather comments here first. Cheers, =) -- Felipe.

4 7

Adding Html formatting to formlets
by Alberto G. Corona 03 Feb '12

03 Feb '12

I came across the idea that is easy to define additional operators to Text.FormLets for adding custom HTML formatting. Had anyone tried that? For example to enclose the Prod formulary in a Table using Text.XHtml tags. I defined additional operators <<< and <++ for enclosing and prepending Html to a formLet, respectively: >data Prod= Prod{pname :: String, pprice :: Int} >getProd= table <<< ( > Prod <$> tr <<< (td << "enter the name" <++ td <<< getString (pname <$> mp)) > <*> tr <<< (td << "enter the price" <++ td <<< getInt ( pprice <$> mp))) even: >p << "paragraph" <++ getProd ++> (more Html stuff) is possible or even it is possible an operator <+> > getProd <+> someOtherStuff to return Either Prod OtherStuff I did it in my own version of FormLets. So It is too heavy to put here a running example. It is part of a package that I will upload soon to hackage. This also may work for embedding formLets in other haskell HTML formats besides Text.XHtml.

2 2

FYI: conduit 0.1 is buggy?
by Kazu Yamamoto 03 Feb '12

03 Feb '12

Hello, This is just for your information. I have run the Migthy web server based on conduit 0.1/WAI 1.0 on a real world server for severals days. And I found Mighty dies sometimes. I suspect that conduit 0.1 is buggy. I'm not sure but the socket leak problem might affect. I compiled Mighty with conduit 0.2 and run it to watch what will happen. --Kazu

2 1

Upcoming WAI change: flushing
by Michael Snoyman 26 Jan '12

26 Jan '12

Hi all, I've just pushed a relatively minor change to the WAI spec to Github, which ties off the last hole in the specification I'm aware of. One annoyance in creating streaming responses is the issue of flushing. By using Builders, it's more difficult to make a truly streaming, realtime app, as the server will wait until a buffer is filled before sending any data to the client. This is actually a very easy problem to solve. blaze-builder provides a value called `flush` that forces the buffer to be sent, even if it's not full. The problem arises when we add one more piece: the gzip middleware. With gzip, we have an extra layer of buffering in place.[1] We need some way to force gzip to flush the buffer as well. I've put together patches to zlib-bindings, conduit, blaze-builder-conduit, zlib-conduit, and wai, that do the following: * zlib-bindings can now explicitly flush a buffer. * conduit exposes a new datatype: `data Flush a = Chunk a | Flush` * blaze-builder-conduit exposes a new function: builderToByteStringFlush, that keeps flush boundaries intact * zlib-conduit similarly has compressFlush/decompressFlush * The type of ResponseSource now has a stream of `Flush Builder` instead of `Builder` I've updated the affected WAI packages. This may seem like a major overhaul, but it actually has very limited scope. The plus side is that we can now easily do something like an eventsource app that has gzip compression applied. Please let me know your thoughts on this, or if people know of any other holes in WAI that should be plugged right now as well. Michael [1] Regarding previous discussions of using a ByteString instead of a Builder for the stream: this issue would affect either a Builder or ByteString approach, and is thus an orthogonal issue.

3 5

ANN: happstack-server 6.5.1
by Jeremy Shaw 23 Jan '12

23 Jan '12

I am pleased to announce the release of happstack-server 6.5.1. Happstack is a powerful, flexible and well documented Haskell web development framework. For more information see: http://www.happstack.com/ Changes in this release include: - support for https:// (aka, SSL/TLS) https://groups.google.com/group/happs/browse_thread/thread/d92c24a7a81adfe8 - directory listings now sorted in alphabetical order - added Happstack class instances for ReaderT, WriterT, StateT, and RWST - happstack-server now compiles without producing any warnings - various code cleanup and formatting Discussion here: http://www.reddit.com/r/haskell/comments/os5kb/ann_happstackserver_651_http…

1 0

[wai] wai-eventsource not released with wai 1.0?
by Bardur Arantsson 19 Jan '12

19 Jan '12

Hello, Was it intentional that wai-eventsource was not released simultaneously with WAI 1.0? Cheers,

2 2

Split up authenticate and yesod-auth?
by Michael Snoyman 19 Jan '12

19 Jan '12

Hi all, When I started writing the authenticate package, I was the sole author of it, and I understood (to some degree) every protocol I added support for. If there was a bug report, feature request, or anything else, I had a fair idea of either how to solve it or if making the requested change would break something else. Fortunately, many people have contributed to the authenticate (and yesod-auth) packages, and the above paragraph is no longer true. I don't know what's going on with OAuth or Kerberos besides a most basic understanding, and I'm not in a position to maintain those myself. Additionally, some people are discussing adding more backends. While I want to make it clear that I appreciate the contributions, this situation has a few downsides: * When some kind of request or bug report comes to me, I have to route it to the right person, which just adds an extra step to the process. * Same thing when people ask me for assistance. * In theory, when upgrading, I could break code without even knowing it. (I don't think that's actually happened though). * The packages are both becoming rather large. On the flip side, it's very nice to have all the authentication modules centralized as they currently are. So the question is: how should future development continue? I see three choices: 1. Continue as-is. New modules can be added to these two packages, and I'll just route inquiries to the appropriate person. One minor change I'll insist on here is that authors specify in the module docs who the maintainer is, and I'll add them as contributors on Github. 2. No new modules will be accepted into these packages, they'll need to go into their own packages. 3. Even existing modules for which I'm not really the maintainer will be split off into their own packages. For options (2) and (3), we can update the docs for authenticate and yesod-auth to point to external packages that provide additional auth backends. Michael

2 2

Please upgrade http-enumerator and/or http-conduit
by Michael Snoyman 17 Jan '12

17 Jan '12

Hi all, Thanks to Felipe for catching this issue[1]. Both http-enumerator and http-conduit will not properly reject invalid certificates. I've released updated versions of both packages: http-enumerator-0.7.2.4 http-conduit-1.1.2.2 All users are recommended to upgrade. Michael [1] https://github.com/snoyberg/http-conduit/pull/6

1 0

ANNOUNCE: wai-routes-0.1
by Anupam Jain 14 Jan '12

14 Jan '12

Hi, I couldn't find any library that provides typesafe URLs for plain Wai applications so I modified the code in Yesod.Dispatch (yesod-core) and created wai-routes. This is my first time writing TH code so I stuck to "tweaking" the existing functionality. http://hackage.haskell.org/package/wai-routes Currently it allows you to define type safe URLs in a manner similar to Yesod. It also provides Middleware to easily insert dispatching into your application. A sample application that provides a JSON API (using aeson) - ============================================ -- A useful type synonym type UserId = Text -- Define the JSON instance data User = User { name::Text, uid:: UserId } deriving (Show, Read, Eq) instance ToJSON User where toJSON x = object [ "name" .= (name x), "uid" .= (uid x) ] -- Define the handlers getUserR :: UserId -> Application getUserR uid _req = return $ responseLBS statusOK headers json where user = User { name = "Anon Amos", uid = uid } json = encode user headers = [("Content-Type", "application/json")] getUsersR :: Application getUsersR _req = return $ responseLBS statusOK headers json where userids = (["anon","john","jane"]::[Text]) json = encode userids headers = [("Content-Type", "application/json")] -- Generate the routing datatype and the Route instance -- The type generated will be named "UserRoute" mkRoute "User" [parseRoutes| /users UsersR GET /user/#UserId UserR GET |] -- Now you can use dispatch function (passing it your route datatype) main :: IO () main = run 8080 $ dispatch (undefined::UserRoute) $ staticApp defaultFileServerSettings ============================================ Thanks, Anupam Jain

2 1