On 02/15/2011 08:02 PM, Michael Snoyman wrote:
> On Wed, Feb 16, 2011 at 2:05 AM, Jeremy Fitzhardinge <jer...@goop.org> wrote:
>> On 02/15/2011 02:14 PM, Vincent Hanquez wrote:
>>> 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.
>> I don't really see why hoauth needs to make its own http requests at
>> all, except perhaps as a convenience. At heart, doesn't it just need to
>> set up requests and parse certain responses? It could almost be pure,
>> aside from needing to get timestamps and generate nonces (which, btw,
>> doesn't seem to be using a cryptographically strong RNG). But that
>> suffers from not having standard request/response types.
>>
>>> you should check the twidge twitter utility and/or yesod-auth-oauth, that
>>> both
>>> uses curl/hoauth.
>> Thanks for the pointers. Does Network.Curl support interleaved
>> processing on infinite streams?
>>
>>> 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),
>> Yes, that's what I thought, but http-enumerator dips into it for its
>> http response types.
> This is something that Aristid has been working on with his http-types
> package: it's supposed to be a more generic package that defines types
> like HTTP status, request method, header key/value, etc.
Ah, good, thanks for the pointer. That's the sort of package that
should exist.
> In the next
> iteration of WAI/http-enumerator, they will both depend on http-types
> most likely. But since http-types did not exist until recently,
> http-enumerator borrowed the Status and CIByteString types from WAI.
Yes, that's reasonable. (Though I have questions about CIByteString...)
> I think in general it's a nice goal to get all HTTP client libraries
> to accept identical interfaces, but in practice I don't think it can
> ever happen.
I don't think the need identical APIs. I think they need to settle on
some common types so that its possible to compose them to get the best
of each.
> I've gotten a number of emails from people switching to
> http-enumerator because it's faster than HTTP. Additionally, since
> HTTP uses String instead of ByteString for its standard functions, it
> can be very tricky to get character encodings correct.
Yes. And for my use-case - dealing with an infinite http stream -
enumerators are much more comforting with respect to space use.
> The fact is, I wrote http-enumerator specifically to support OpenID
> logins on haskellers.com, so in many ways it wouldn't surprise me for
> it to be a good fit for hoauth.
>
> On a separate, but related, note, I've been trying to consolidate a
> number of third-party login systems (OpenID, Facebook, RPXNow) into a
> single package called authenticate[1]. I hadn't actually noticed
> hoauth until now, but it looks like it would be a perfect addition to
> authenticate. There would basically be two ways to achieve this: 1)
> have authenticate depend on hoauth or 2) move the code from hoauth to
> authenticate. My guess is we would both prefer the first choice, but
> I'd like to know if you are making any major API changes before doing
> anything.
I had a look at authenticate in the context of Yesod, and it looks very
interesting. However, it's not clear to me whether it does exactly the
same thing. OAuth allows a client to authenticate to the twitter
service on behalf of a user and access protected resources. As I
understand authenticate, it allows a server app to use
Facebook/OpenID/etc as a source of authentication information locally,
but doesn't necessarily allow it to act on the user's behalf on, say,
Facebook.
Or am I missing something?
Thanks,
J
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
