In the past I have gotten a sqlite C binding working through an old alpha version of the ffi. It was never completely stable and was failing in the ffi. But it was doable. I had limited time and couldn't hunt down where it was failing in the ffi. I didn't have any requirements to use the FFI and was just exploring the possibility. So I moved back to SQLite using JGC's TCP server [1]. Which was a great solution! It wasn't especially portable between mac and linux (ie deploying it to my web server). But it was fast to set up and robust on the mac.
Similarly I worked on MySQL bindings but they were never robust enough to use especially in comparison to the JGC solution. This was a few versions ago before the ffi was flushed out. Maybe a similar TCP server using MySQL would make sense. I know it worked really well for me. I had problems making it portable (between Ubuntu / FreeBSD). But after those problems were worked out it was stable.
Good luck. I'm interested in what ends up working for you.
One note: I needed to change the dbslayer source code, prior to making the install, in order to eliminate the spaces that aw's combinator would choke on. It was a trivial change though...
[EDIT: Correction I was using an older version of aw's combinator - the new version handles spaces]
That's cool. It's a neat idea that by default (if there isn't an explicit reason why you have to do something else), all interfaces can be HTTP, and as a bonus use JSON as your data interchange format...
Exactly. The concept is great. Even now when I am starting to learn haskell, the first thing I am doing checking out haskells' JSON parser to communicate via HTTP. Conceptually I can keep doing this and communicate easily across any language. And since SQL to URL is so basic I can re-use/apply dbslayer to any language too.
