On Wed, Feb 16, 2011 at 8:38 AM, Jeremy Fitzhardinge <jer...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe