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