On Thu, Jan 19, 2012 at 5:22 AM, Erik de Castro Lopo wrote:

Michael Snoyman wrote:

...

However, WAI and Warp are mostly ready now, just needing a bit more testing. If people want to give me some feedback on the readiness of them, and would like them released earlier, I'm definitely flexible.

Meanwhile: yes, the Github version is conduit-based.

Michael,

I'm having some trouble getting the right set of dependencies for Conduit versions of wai and warp. At the moment I'm stuck on asn1-data; every version I can find of that seems to depend on enumerator.

Is there a simple recipe somewhere for build conduit versions of wai and warp?

Cheers, Erik

We can still have a conduit-based version of WAI and Warp, even if an underlying package uses enumerator. The enumerator usage from asn1-data doesn't leak into WAI or Warp at all[1]. We could ask Vincent to consider moving over to attoparsec-conduit instead, but I don't think there's any strong need for this. Michael [1] In fact, asn1-data isn't even a dependency for WAI or Warp, though it is for http-conduit

On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman wrote:

We can still have a conduit-based version of WAI and Warp, even if an underlying package uses enumerator. The enumerator usage from asn1-data doesn't leak into WAI or Warp at all[1]. We could ask Vincent to consider moving over to attoparsec-conduit instead, but I don't think there's any strong need for this.

Speaking of the migration issue; it should be possible to have an enumerator <-> conduit wrapper library to help people continue to use their enumerator-based code for awhile (and vice-versa). G -- Gregory Collins

On Thu, Jan 19, 2012 at 10:35 AM, Vincent Hanquez wrote:

On 01/19/2012 08:14 AM, Gregory Collins wrote:

...

 Speaking of the migration issue; it should be possible to have an  enumerator <-> conduit wrapper library to help people continue to use  their enumerator-based code for awhile (and vice-versa).

A bit out of topic and definitely not answering the question, but for asn1-data, i want to move away from the data feeding business, and just relying on the attoparsec API.

That let the user choose the feeding "style" by plugin either an existing attoparsec plugin package (attoparsec-{conduit,enumerator,iteratee}) or dealing with the Result type directly.

This is also possible when using cereal (Data.Serialize).

I think more libraries in the enumerator camp or iteratee camp should look if they need to control input or not. unless there's something i missed :-)

-- Vincent @vincenthz

That's the reason, for example, that zlib-bindings exists. It's a mid-level binding to the zlib C library. I wouldn't want to write code against it in general, but it makes it very easy to create zlib-enum and zlib-conduit. Michael

On 01/19/2012 03:22 AM, Erik de Castro Lopo wrote:

Michael Snoyman wrote:

...

However, WAI and Warp are mostly ready now, just needing a bit more testing. If people want to give me some feedback on the readiness of them, and would like them released earlier, I'm definitely flexible.

Meanwhile: yes, the Github version is conduit-based.

Michael,

I'm having some trouble getting the right set of dependencies for Conduit versions of wai and warp. At the moment I'm stuck on asn1-data; every version I can find of that seems to depend on enumerator.

Humm, yeah, a bit sad, I'ld like to move away from them as well, and probably just moving to a raw-attoparsec-based API would be fine. But asn1-data is not part of wai/warp, and just a sub dependency of tls. so you can just have enumerator installed for it for the time being. -- Vincent @vincenthz