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