On Tue, Feb 15, 2011 at 10:42:57AM -0800, Jeremy Fitzhardinge wrote:
And since I'm still trying to get my head around enumerators, I may have that aspect of things completely wrong. I haven't even tried running any of this yet, so I don't know if I've made any non-type errors.
Am I even barking up the right tree at all? Should I try to be using hoauth this way at all, or should I just hack it up to work within http-enumerator? That seems counter-productive.
A general comment:
There are many partially functional http packages in hackage. It seems to me that rather than requiring one package be a complete http library, we would get further by allowing different packages to implement different aspects of http, so long as they can all be composed in a reasonable way. At the very least, is it really necessary for hoauth to define its own Request/Response types? Would it be worthwhile trying to define general types which all http packages could use? Is that the goal of Network.Wai? What about the HTTP package? Should I just use that instead? What about Network.Curl?
Clearly, http-enumerator is the best package for doing http/https. however since it's pretty new, lots of package still uses their own abstraction for doing things. While it may be possible to retrofit hoauth to use http-enumerator, using the httpclient typeclass, that's going to be hard to fit the full enumerator interface on it, so you won't benefit of streaming; You may as well just use network.curl for now, which is what i've seen used with hoauth. you should check the twidge twitter utility and/or yesod-auth-oauth, that both uses curl/hoauth. It would be really useful to see an hoauth fully using enumerator and http-enumerator (and not redefining a boat load of stuff), but IMO you'll need to understand enumerators before tackling such a challenge. Also Wai is for abstracting server side "transport" (cgi/fastcgi/others), and the HTTP package doesn't do TLS. -- Vincent