Re: [Haskell-cafe] Contributing to http-conduit

Indeed, I disagree on 2. Sometimes there is an API and cookies are just not part of it (and redirects are). Aristid Am 23.01.2012 08:16 schrieb "Michael Snoyman" :

The only times cookies would be used would be:

1. If you explicitly use it. 2. If you have redirects turned on, and a page that redirects you also sets a cookie.

I would think that we would want (2) to be on regardless of user setting, do you disagree?

Michael

On Mon, Jan 23, 2012 at 8:46 AM, Aristid Breitkreuz wrote:

...

Just make sure Cookie handling can be disabled completely.

Aristid

Am 23.01.2012 07:44 schrieb "Michael Snoyman" :

...

On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield 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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe