14:36:52 <Entroacceptor> btw., who trolled http://www.haskell.org/haskellwiki/Applications_and_libraries/Network ?
14:37:07 <Entroacceptor> it says about happstack:     Monadic ACID transactions, a high performance HTTP server, an SMTP server, a DNS server, mail delivery agent, XML and XSLT, and more.
14:41:44 <user1> Entroacceptor: happs originally had all these features
14:42:36 <Entroacceptor> wow
14:43:03 <user1> http://happs.org
14:44:21 <Entroacceptor> still no dns server there ;)
14:44:58 <Entroacceptor> no wonder it imploded
14:45:31 <etarasov> I'm not sure how well dns in happs was
17:26:46 <stepcut> there was a DNS server in HAppS at one point in time. I remember it
17:26:57 <stepcut> one of my ongoing goals is to have less and less in happstack :)
17:27:08 <stepcut> acid-state is now free (thanks to Lemmih)
17:27:17 <stepcut> and switching to wai will result in less code that is happstack specific
17:27:49 <stepcut> and will also result in happstack-utils being essentially dead as well, as it won't be used by anything anymore
17:28:08 <stepcut> of course, we have also added a bunch of new things like happstack-heist, happstack-authenticate, etc
17:39:51 <etarasov> will happstack-server go away?
17:41:21 <stepcut> no
17:41:47 <stepcut> it will just use wai for the low-level stuff instead the lazy I/O based backend we have now
17:42:07 <stepcut> been on the TODO list for years.. but now there is actually a WAI backend worth using :p
17:43:32 <stepcut> wai itself is pretty low-level. It basically provides a Request type, and Response type, and a function, Request -> IO Response
17:44:55 <stepcut> so, things like the routing combinators, or high-level functions for looking up key/value pairs in the request data will still live on in happstack-server
17:45:34 <etarasov> It seems that api will changes
17:45:42 <etarasov> wai uses iterators
17:45:47 <stepcut> it most happstack apps, you never deal with the Request / Response types directly anyway. You use other functions that interact with Request / Response
17:46:17 <etarasov> I often generate response with toResponse
17:46:31 <stepcut> the API could, in fact, change very little. If you use 'toResponse' to convert values to a Response, then you wouldn't even notice if we changed from lazy bytestrings to enumerators
17:47:08 <stepcut> however, we will probably take this opportunity to intentially break some of the API. For example, instead of having, method, methodSP, methodOnly, and methodM, we will consolidate down to a single 'method' function
17:47:20 <stepcut> and we might switch from String to Text in a number of places
17:47:47 <etarasov> what about Happstack.Server.FileServe.BuildingBlocks ? will these functions change?
17:48:05 <stepcut> basically, we will take inventory of everything as we move it to the wai backend, and thing figure out how we could simplify / improve things
17:48:17 <etarasov> Strings are easily convertable to Text I think
17:48:32 <stepcut> etarasov: I don't expect major changes to BuildingBlocks.. unless people have requests for things they want changed
17:49:14 <stepcut> yeah
17:49:23 <etarasov> so, I'll stay with happstack for a long time =)
17:49:37 <stepcut> The end result should be something that is very similar to what we have now. Just a  little cleaner and more modern.
17:50:28 <stepcut> I have a lot of code that uses the current Happstack.. so any changes to the API affect me quite directly :p