I am experimenting in that field, too. I'll tell you what I have so
far, which is mostly just ideas and some bits of code. As many others,
I'm stuck without `pipes-parse` and `pipes-attoparsec`, but luckily
those are coming out really soon :)
My plan currently looks like this:
First, I think that it would be nice if we manage to split the HTTP
problem in three core and reusable packages:
- `pipes-www-client`: This package would be the pipes counterpart to
`http-conduit` and `http-streams`, that is, an HTTP(S) client,
hopefully lightweight. And it would be built on top of
`pipes-attoparsec`, `pipes-network`, `pipes-network-tls`,
`pipes-zlib`, among other non-pipes related packages.
- `pipes-www-server`: This would be an HTTP server built with the same
tools used by `pipes-www-client`. Jeremy Shaw is working in his
`hyperdrive` pipes-based HTTP server, and he has quite some experience
in this field. Hopefully we can work on this together and lay down a
healthy foundation for future HTTP projects, and maybe `hyperdrive`
itself can occupy this place.
- `pipes-www-core`: I'd like to put here as many reusable parts as
possible. Say types and the core API that defines how to deal with a
Request, so that it can be used by other packages different than
`pipes-www-server`. That is, I want this package to be similar to
conduit's WAI, but hopefully covering both server-side and client-side
concerns. I don't know if this makes sense, maybe it doesn't, but I'll
think more about it.
I'm particularly interested in getting `pipes-www-core` and
`pipes-www-client` right now, since I'll need to use them in the real
world soon :)
I've been thinking about the best way to deal with parsing HTTP
Request and HTTP Responses in a compositional manner, and I've
identified problems similar to those you had when writing `pipes-tar`.
My current idea is that within the “incoming HTTP message consumer”
pipeline I'll parse the HTTP message header and handle that header to
an user-provided function that will return an apropiate `Consumer p
ByteString m r` able to parse the rest of the incoming message body.
I've made some experiments with this, but nothing serious until
`pipes-parse` and `pipes-attoparsec` are out.
Given the context of this conversation, I guess that by `pipes-http`
you are referring to “client side HTTP”, right? Let's work together on
this. In this project I started, trying to work my way towards
`pipes-www-server`, I already have some types and attoparsec parsers
that I plan to use: https://github.com/k0001/seldom
(most of the
original code there belongs to the Snap and Yesod team, I'm thankful
to them for sharing the code as they do).