Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On Tue, Feb 15, 2011 at 11:49:16PM -0200, Diego Souza wrote: Hi, thanks for the feedbacks. They sound very reasonable. Going back in time, the first version was in fact a pure library. However, at some point I changed this as I thought it would make it easier to use, which might have been a mistake of mine. Back then http-enumerator wasn't available and after it did I haven't considered using it until now. I'm just concerned about changing the interface once more, but it might be justified. Perhaps splitting it into the pure oauth functions as used to be in the beginning and another one that puts the http layer, in case one finds it convenient. That might mitigate this problem, and perhaps, avoid changing the interface. What you guys think? I think such separation would be great ! however ultimately, i don't think there's any reason why would you not target http-enumerator directly and drop all the abstraction ? As long as thing changes, you might consider using crypto-api CPRNG classes instead of random. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
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
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
Thanks! I'm going to start working on this. Creating specific typeclasses is a good idea and I also believe that these changes can be done without breaking existing code. I'll see how that goes and keep you guys updated. On Wed, Feb 16, 2011 at 4:27 AM, Jeremy Fitzhardinge jer...@goop.org wrote: On 02/15/2011 05:49 PM, Diego Souza wrote: Hi, thanks for the feedbacks. They sound very reasonable. Going back in time, the first version was in fact a pure library. However, at some point I changed this as I thought it would make it easier to use, which might have been a mistake of mine. Yes, I think its a good idea to keep things simple and pure to ease composition. I'm just concerned about changing the interface once more, but it might be justified. Perhaps splitting it into the pure oauth functions as used to be in the beginning and another one that puts the http layer, in case one finds it convenient. That might mitigate this problem, and perhaps, avoid changing the interface. Since there seem to be a number of existing users of your API, it would be rude to break it on them. You can implement a clearly defined two-layer API for the package: a mostly pure layer which deals with the basics of settings up OAuth requests and responses, and then the current API layered on top of it. The main problem is dealing with all the different Request/Response types. But if you can narrow down the sets of operations you need for each and define typeclasses with the appropriate functions, it should be fairly to make the existing types instances of those classes (ie, akin to HttpClient, but avoiding the IO where possible). J -- ~dsouza yahoo!im: paravinicius gtalk: dsouza...@gmail.com gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
I was thinking in separating the core and http functions in order to be able to provide implementation for http-enumerator without breaking existing clients. Also the ones who don't need http interface don't need to use the full stack. I was not aware of CPRNG classes, thanks for that. I'll definitely take a look on this! Thanks, On Wed, Feb 16, 2011 at 8:33 AM, Vincent Hanquez t...@snarc.org wrote: On Tue, Feb 15, 2011 at 11:49:16PM -0200, Diego Souza wrote: Hi, thanks for the feedbacks. They sound very reasonable. Going back in time, the first version was in fact a pure library. However, at some point I changed this as I thought it would make it easier to use, which might have been a mistake of mine. Back then http-enumerator wasn't available and after it did I haven't considered using it until now. I'm just concerned about changing the interface once more, but it might be justified. Perhaps splitting it into the pure oauth functions as used to be in the beginning and another one that puts the http layer, in case one finds it convenient. That might mitigate this problem, and perhaps, avoid changing the interface. What you guys think? I think such separation would be great ! however ultimately, i don't think there's any reason why would you not target http-enumerator directly and drop all the abstraction ? As long as thing changes, you might consider using crypto-api CPRNG classes instead of random. -- Vincent -- ~dsouza yahoo!im: paravinicius gtalk: dsouza...@gmail.com gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On 02/16/2011 02:57 AM, Michael Snoyman wrote: 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. Mostly it was a semantic niggle that bytestrings don't have a notion of case, so CI- is meaningless. CIAscii at least makes some sense. Does Text support the notion of case-insensitive types? 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. OK. J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On 02/16/2011 06:00 AM, Diego Souza wrote: I was thinking in separating the core and http functions in order to be able to provide implementation for http-enumerator without breaking existing clients. Also the ones who don't need http interface don't need to use the full stack. I was not aware of CPRNG classes, thanks for that. I'll definitely take a look on this! I just sent you a pull-request for this on github. J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On Wed, Feb 16, 2011 at 7:20 PM, Jeremy Fitzhardinge jer...@goop.org wrote: On 02/16/2011 02:57 AM, Michael Snoyman wrote: 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. Mostly it was a semantic niggle that bytestrings don't have a notion of case, so CI- is meaningless. CIAscii at least makes some sense. Does Text support the notion of case-insensitive types? No, I don't think so. Even if it did, it would be inappropriate to use Text, since a Text value can contain any unicode point, while HTTP headers cannot. 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. OK. J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
Thanks! I'll merge it tonight :-) On Wed, Feb 16, 2011 at 3:33 PM, Jeremy Fitzhardinge jer...@goop.org wrote: On 02/16/2011 06:00 AM, Diego Souza wrote: I was thinking in separating the core and http functions in order to be able to provide implementation for http-enumerator without breaking existing clients. Also the ones who don't need http interface don't need to use the full stack. I was not aware of CPRNG classes, thanks for that. I'll definitely take a look on this! I just sent you a pull-request for this on github. J -- ~dsouza yahoo!im: paravinicius gtalk: dsouza...@gmail.com gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to use http-enumerator with hoauth?
Hi,
I'm trying to use http-enumerator with Twitter's streaming API, which
requires OAuth authentication.
I was hoping to use the hoauth package for this, but it seems that
combining with with http-enumerator is pretty awkward.
In principle, it should be straightforward since hoauth defines a
HttpClient typeclass, and so I would just need to write an instance for
http-enumerator.
But in practice it is pretty awkward for a few reasons. One is that
both packages define their own Request and Response types - however they
are semantically identical, so writing conversion functions is tedious
but possible.
However, I can't work out how to implement error handling;
http-enumerator uses the Control.Failure exception mechanism for
returning errors, but I can't work out how to fit that into HttpClient's
runClient function.
If I use http rather than httpRedirect, I can avoid this to some
extent (since http doesn't use Failure HttpException m), but I still
can't get it to typecheck.
I can get a simple non-streaming instance to typecheck using httpLbs
(but again, not httpLbsRedirect):
data HttpOAuth = HttpOAuth { }
instance O.HttpClient HttpOAuth where
runClient c r = (HE.httpLbs . http_cvt_request) r = return . cvt
where
cvt :: HE.Response - Either String O.Response
cvt r@(HE.Response st _ b) | 200 = st st 300 = Right $
http_cvt_response r
| otherwise = Left $ HTTP
status ++ show st
However, I can't get the streaming version to type check at all:
newtype HttpOAuthStream a m b = HttpOAuthStream { iter :: W.Status -
W.ResponseHeaders - DE.Iteratee a m b }
instance O.HttpClient (HttpOAuthStream a m b) where
-- runClient :: (MonadIO m) = c - Request - m (Either String Response)
runClient c r = liftM cvt $ DE.run $ HE.http (http_cvt_request r) (iter c)
cvt :: Show a = Either a HE.Response - Either String O.Response
cvt (Left a) = Left $ show a
cvt (Right r) = Right $ http_cvt_response r
(Full code below)
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?
Thanks,
J
import qualified Data.Enumerator as DE
import qualified Data.ByteString.Char8 as C8
import Control.Monad (liftM)
import Control.Applicative (($), (*), (|), empty, pure)
import Control.Arrow (first, second, (***))
import qualified Network.OAuth.Consumer as O
import qualified Network.OAuth.Http.HttpClient as O
import qualified Network.OAuth.Http.Request as O
import qualified Network.OAuth.Http.Response as O
import qualified Network.HTTP.Enumerator as HE
import qualified Network.Wai as W
import Data.List (intercalate)
import Control.Failure
import Control.Exception (SomeException)
-- Convert a Network.OAuth.Http.Request into a Network.HTTP.Enumerator.Request
-- What. A. Pain.
http_cvt_request :: O.Request - HE.Request
http_cvt_request oar = HE.Request method secure host port path query headers
body
where method = C8.pack . show . O.method $ oar
secure = O.ssl oar
host = C8.pack . O.host $ oar
port = O.port oar
path = C8.pack . intercalate / $ O.pathComps oar
query = packpair $ (O.toList . O.qString $ oar)
headers = (first W.mkCIByteString) . packpair $ (O.toList .
O.reqHeaders $ oar)
body = O.reqPayload oar
-- Convert a Network.HTTP.Enumerator.Response into a Network.OAuth.Http.Response
-- See above.
http_cvt_response :: HE.Response - O.Response
http_cvt_response her = O.RspHttp status reason headers payload
where status = HE.statusCode her
reason = -- ?
headers = O.fromList $ (unpackpair . first W.ciOriginal) $
HE.responseHeaders her
payload = HE.responseBody her
mappair f (a,b) = (f a, f b)
packpair = mappair C8.pack
unpackpair = mappair C8.unpack
newtype HttpOAuthStream a m b = HttpOAuthStream { iter :: W.Status -
W.ResponseHeaders - DE.Iteratee a m b }
instance O.HttpClient (HttpOAuthStream a m b) where
-- runClient :: (MonadIO m) = c - Request - m (Either String
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
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. the HTTP package doesn't do TLS. That's unfortunate, but it seems like it could have been a fairly easy thing to address. Or does it have other deficiencies? Thanks, J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
Hi, thanks for the feedbacks. They sound very reasonable. Going back in time, the first version was in fact a pure library. However, at some point I changed this as I thought it would make it easier to use, which might have been a mistake of mine. Back then http-enumerator wasn't available and after it did I haven't considered using it until now. I'm just concerned about changing the interface once more, but it might be justified. Perhaps splitting it into the pure oauth functions as used to be in the beginning and another one that puts the http layer, in case one finds it convenient. That might mitigate this problem, and perhaps, avoid changing the interface. What you guys think? Again, thanks, On Tue, Feb 15, 2011 at 10:05 PM, 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. the HTTP package doesn't do TLS. That's unfortunate, but it seems like it could have been a fairly easy thing to address. Or does it have other deficiencies? Thanks, J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- ~dsouza yahoo!im: paravinicius gtalk: dsouza...@gmail.com gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
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. 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. 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. the HTTP package doesn't do TLS. That's unfortunate, but it seems like it could have been a fairly easy thing to address. Or does it have other deficiencies? 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. 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. Michael [1] http://hackage.haskell.org/package/authenticate ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On 02/15/2011 05:49 PM, Diego Souza wrote: Hi, thanks for the feedbacks. They sound very reasonable. Going back in time, the first version was in fact a pure library. However, at some point I changed this as I thought it would make it easier to use, which might have been a mistake of mine. Yes, I think its a good idea to keep things simple and pure to ease composition. I'm just concerned about changing the interface once more, but it might be justified. Perhaps splitting it into the pure oauth functions as used to be in the beginning and another one that puts the http layer, in case one finds it convenient. That might mitigate this problem, and perhaps, avoid changing the interface. Since there seem to be a number of existing users of your API, it would be rude to break it on them. You can implement a clearly defined two-layer API for the package: a mostly pure layer which deals with the basics of settings up OAuth requests and responses, and then the current API layered on top of it. The main problem is dealing with all the different Request/Response types. But if you can narrow down the sets of operations you need for each and define typeclasses with the appropriate functions, it should be fairly to make the existing types instances of those classes (ie, akin to HttpClient, but avoiding the IO where possible). J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
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
