Conduit versions of wai and warp?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Conduit versions of wai and warp?

Erik de Castro Lopo-34
Hi Michael,

The current versions of wai and warp:

    http://hackage.haskell.org/package/wai
    http://hackage.haskell.org/package/warp

still seem to be the versions that use enumerator.

Any idea when the Conduit versions might show up on Hackage?

Until then, should I be grabbing these packages from Github?

Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Michael Snoyman
On Wed, Jan 18, 2012 at 2:22 AM, Erik de Castro Lopo
<[hidden email]> wrote:

> Hi Michael,
>
> The current versions of wai and warp:
>
>    http://hackage.haskell.org/package/wai
>    http://hackage.haskell.org/package/warp
>
> still seem to be the versions that use enumerator.
>
> Any idea when the Conduit versions might show up on Hackage?
>
> Until then, should I be grabbing these packages from Github?
>
> Cheers,
> Erik
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/

Funny, I just got a similar question on the Yesod mailing list.
Currently, the plan is to release WAI/Warp 1.0 and Yesod 0.10 towards
the end of the month. 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Erik de Castro Lopo-34
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
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Michael Snoyman
On Thu, Jan 19, 2012 at 5:22 AM, Erik de Castro Lopo
<[hidden email]> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Erik de Castro Lopo-34
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.

Ah, got it now. Thanks.

Look forward to this stuff hitting Hackage.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Vincent Hanquez
In reply to this post by Erik de Castro Lopo-34
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Gregory Collins-3
In reply to this post by Michael Snoyman
On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman <[hidden email]> 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 <[hidden email]>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Vincent Hanquez
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Michael Snoyman
On Thu, Jan 19, 2012 at 10:35 AM, Vincent Hanquez <[hidden email]> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Conduit versions of wai and warp?

Michael Snoyman
In reply to this post by Gregory Collins-3
On Thu, Jan 19, 2012 at 10:14 AM, Gregory Collins
<[hidden email]> wrote:

> On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman <[hidden email]>
> 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).

I think it's easier said than done. Some conversions should be
straight-forward: turning a Source into an Enumerator, for example.
But others won't be possible without dirty hacks (e.g., Enumerator to
Source will likely require forking a thread and using Chan), while
others may be completely impossible (Enumeratee to Conduit). I agree
such a package is a good idea, and I'd be happy to help anyone who
wants to step up to the plate on it, but I'm not very hopeful that it
will be incredibly useful.

Michael

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe