[Haskell-cafe] How to use http-enumerator with hoauth?

[Michael Snoyman]

On Wed, Feb 16, 2011 at 8:38 AM, Jeremy Fitzhardinge <jeremy at goop.org> wrote:
> On 02/15/2011 08:02 PM, Michael Snoyman wrote:
>
>>  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 have yet to write to the mailing lists about it, but likely there
will be a rename/expansion based on a recommendation by Johan.
Basically, we need two datatypes: Ascii and CIAscii. I'm not sure if
that addresses your questions though.

>> 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 agree. I think this will be a good move. At the very least, having
WAI and http-enumerator share the same types provides for some nice
features like proxying HTTP services.

>> 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?

I think there's a big overlap between third-party authentication and
access to protected resources. Check our the Facebook module: in
addition to just "login" support, it allows access to the graph API
using the secure token Facebook gives back. I don't think having extra
functionality beyond pure authentication should be a reason to exclude
hoauth from authenticate.

Michael