-
-
Notifications
You must be signed in to change notification settings - Fork 36
scrape safe/idempotent properties from IANA, expose getters on module… #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
You may want to check first before working on something if it helps. There is already an iana branch with the WIP on this. Please base work on that branch, not master. |
dougwilson
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Work for pulling from IANA (issue #15) needs to be based on the iana branch; adding other exports needs to be a separate PR from the IANA pulling work.
|
I'm new to making contributions on GitHub, didn't think to look at branches, obvious in hindsight. Will keep that in mind for the future. Looks like you did the same thing I did but also wrote your own JSON serializer. Just curious, was that for fun, or is there a particular benefit? If it sounds good to you, I will branch properly and add the tests I wrote / change the exports in another PR. |
That's OK; I'm happy to help if you wanted to help on an issue I had assigned to myself to do, but you may want to comment in the issue in the future to see how you can help / where to start :)
It's the same pattern I use in the other repos; it ensures that the JSON object keys are always in the same order and don't switch around sometimes by running a YI had just made #15 just as a reminder for me, so didn't write down any details. Pulling down from IANA is intended to completely change what this module is and how exactly the Node.js fallback is supposed to work, which is part of the pull from IANA to make useful work what is the missing part from that branch. The idea is that this module should only provide the methods from IANA and not use that hard-coded list at all. |
Will do! :)
Interesting. Those sort of diffs would be super annoying.
I suppose I don't understand why you would need any fallback at all with this change, given that we have all the methods from IANA in a json file. If IANA gives a method not found in Something like: Is the above pseudocode missing any features you want out of this module? Of course, the above wouldn't work if |
… exports
Issue #15
I wasn't sure of the best interface to provide for getting the safe/idempotent properties. I decided to provide functions 'isSafe' and 'isIdempotent' on the exports. That way, the only change to existing code using this module would be
var methods = require('methods)->var methods = require('methods),methodsI made a dev script to scrape the data from IANA, and store it in a json file. Would you prefer this to be done live instead?