[Haskell-cafe] Contributing to http-conduit

[Myles C. Maxfield]

Alright, that sounds good to me. I'll get started on it (the IORef idea).

Thanks for the insight!
--Myles

On Sun, Jan 22, 2012 at 10:42 PM, Michael Snoyman <michael at snoyman.com>wrote:

> On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield
> <myles.maxfield at gmail.com> wrote:
> > 1. Oops - I overlooked the fact that the redirectCount attribute of a
> > Request is exported (it isn't listed on the documentation probably
> because
> > the constructor itself isn't exported. This seems like a flaw in
> > Haddock...). Silly me. No need to export httpRaw.
> >
> > 2. I think that stuffing many arguments into the 'http' function is ugly.
> > However, I'm not sure that the number of arguments to 'http' could ever
> > reach an unreasonably large amount. Perhaps I have bad foresight, but I
> > personally feel that adding cookies to the http request will be the last
> > thing that we will need to add. Putting a bound on this growth of
> arguments
>
> I completely disagree here. If we'd followed this approach, rawBody,
> decompress, redirectCount, and checkStatus all would have been
> arguments. There's a reason we use a settings data type[1] here.
>
> [1] http://www.yesodweb.com/blog/2011/10/settings-types
>
> > makes me more willing to think about this option. On the other hand,
> using a
> > BrowserAction to modify internal state is very elegant. Which approach do
> > you think is best? I think I'm leaning toward the upper-level Browser
> module
> > idea.
> >
> > If there was to be a higher-level HTTP library, I would argue that the
> > redirection code should be moved into it, and the only high-level
> function
> > that the Network.HTTP.Conduit module would export is 'http' (or httpRaw).
> > What do you think about this?
>
> I actually don't want to move the redirection code out from where it
> is right now. I think that redirection *is* a basic part of HTTP. I'd
> be more in favor of just bundling cookies in with the current API,
> possibly with the IORef approach I'd mentioned (unless someone wants
> to give a different idea). Having a single API that provides both
> high-level and low-level approaches seems like a win to me.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120122/cc1e149c/attachment.htm>