If you're interacting with CouchDB, you have to speak HTTP+JSON.
Even if you send an Accept header that said you only read
text/plain values—which, I should point out, the Couch
documentation says is a valid option—it will send you back
JSON…that is just marked as text/plain.
The HTTP requirement is even more inescapable—the only port open speaks HTTP, Full Stop.
With regard to the JSON requirement, I don't think there's any real
competition: the aeson library is far and away the most popular JSON
library, to the extent that one might be forgiven for not realizing
that there were any others. Although I know the json package exists,
I've never had occasion to so much as read its documentation.
What to use for HTTP is a little less clear, but not, to my eyes, much.
If we got back to my prior statement of requirements, I included:
- choice in streaming library
While I am most familiar with the Conduit ecosystem (largely because
I was using couchdb-conduit, so this might change!), others might
prefer to work with Pipes, or, I suppose, io-streams.
Now that doesn't necessarily mean anything—if I'm doing a request in some function being called as part of someone's stream processing, I don't necessarily need to be integrated with them—usually I just need to write a wrapper that waits for requests, makes them, then yields them.
And for the most part if I'm producing a streaming view, for instance, it's the same thing—I just need to yield each result as I get it; I don't need to be somehow intrinsically tied to the framework.
But still, the http-client package has streaming wrappers for all
three of the mentioned libraries—which suggests that it's easily
compatible—it's got baked-in support for connection pooling, and
good support for incremental input (which is a lot of what we need at
this low level).
So that is the basis upon which I'm going to build what I"m currently thinking I will call couchdb-simple.