Object-oriented API for 3.0

The current API does not make it clear that certain configuration options must be provided to both token generation and verification functions. I would like to suggest changing the API to capture the configuration state in an API class instance, rather than the current function-based approach.

• New classes: HOTP and TOTP.
• Default instances with recommended quick-start configurations.
• As this is a breaking change, either move legacy API to compat module or remove entirely.

[mikepb]

Pure JS prototypical inheritance is tricky. Most people are unfamiliar with it. ES6 introduces the more traditional class inheritance pattern. We can take advantage of Babel to write the new module using ES6.

I agree that a new module would be most appropriate. For lack of a better name, I’ll give it the code name of libotp.

On Feb 28, 2017, at 4:10 AM, Connie Leung [e-mail] wrote:

I am not proficient in OO JS and not sure what inheritance pattern. I can look it up. I think a new module should be used for version 3.0. So speakeasy should be used for v1 and v2 only.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[railsstudent]

@mikepb If use ES6/Babel/class, tools such as webpack/gulp may be need3ed for trancompilation. That should be consider for build process.

@mikepb i have never led in project before and api design is not my strength. i can learn on the side.