On Wed, Feb 16, 2011 at 8:38 AM, Jeremy Fitzhardinge
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