Object-oriented API for 3.0

[mikepb]

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.

[railsstudent]

Sound like a good idea. When this item kickstarts, please let me take part. thanks.

[mikepb]

I can start with whatever contribution you’d like to make. API design, inheritance patterns, quickstart settings, etc. I’d hold off on writing code, though, until people have a chance to provide input.

On Feb 27, 2017, at 9:03 PM, Connie Leung notifications@github.com wrote:

Sound like a good idea. When this item kickstarts, please let me take part. thanks.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/speakeasyjs/speakeasy/issues/82#issuecomment-282943164, or mute the thread https://github.com/notifications/unsubscribe-auth/AAm4bxfzC63qzEo876W7JpGPwl-jeLPWks5rg6qigaJpZM4MN5Ke.

[markbao]

This seems to make sense given the additional functions that we have now that require some of the same configuration options. What's the easiest way to ensure continuity for current module users? I'd like to allow everyone who has Speakeasy in their package.json to continue using it without having to move to another legacy package.

I could potentially see this as a) a separate module that relies on, and is a wrapper of Speakeasy, or b) that Speakeasy is a wrapper for. This is mainly because I'd prefer not to make a huge API change to an existing project that completely changes its architecture – that seems like a separate project to me. But I could be convinced otherwise. Thoughts?

[mikepb]

Could use the name Passcode for the new API and have Speakeasy implement a compatibility layer on top of the new API. Not that many people use Passcode: https://www.npmjs.com/package/passcode

On Feb 28, 2017, at 12:01 AM, Mark Bao notifications@github.com wrote:

This seems to make sense given the additional functions that we have now that require some of the same configuration options. What's the easiest way to ensure continuity for current module users? I'd like to allow everyone who has Speakeasy in their package.json to continue using it without having to move to another legacy package.

I could potentially see this as a) a separate module that relies on, and is a wrapper of Speakeasy, or b) that Speakeasy is a wrapper for. This is mainly because I'd prefer not to make a huge API change to an existing project that completely changes its architecture – that seems like a separate project to me. But I could be convinced otherwise. Thoughts?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/speakeasyjs/speakeasy/issues/82#issuecomment-282969445, or mute the thread https://github.com/notifications/unsubscribe-auth/AAm4b4-mHP2jjvOohiWxGHYa7p1QzYfGks5rg9RWgaJpZM4MN5Ke.

[markbao]

That could work, as long as we make sure the functions, especially verify, absolutely break (i.e. never return truthy) if someone inadvertently updates to passcode 2.x while using code written for 1.x. Or we can see if there are other names that could work.

[mikepb]

libotp

On Feb 28, 2017, at 12:14 AM, Mark Bao notifications@github.com wrote:

That could work, as long as we make sure the functions, especially verify, absolutely break (i.e. never return truthy) if someone inadvertently updates to passcode 2.x while using code written for 1.x. Or we can see if there are other names that could work.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/speakeasyjs/speakeasy/issues/82#issuecomment-282971950, or mute the thread https://github.com/notifications/unsubscribe-auth/AAm4b5aJWRjdPq_jHhm_OmNyttTvzxX0ks5rg9dqgaJpZM4MN5Ke.

[railsstudent]

I am not proficient in OO JS and not sure what inheritance pattern is. 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.

[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 notifications@github.com 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.

[mikepb]

@railsstudent Would you be interested in taking the lead for libotp?

[markbao]

@mikepb Would prefer if you took the lead since it seems like you have a sense of what an ES6/Babel/class inheritance-based implementation would look like

[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.