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
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.rb@gmail.com gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txt