Object-oriented API for 3.0 #82
Comments
|
Sound like a good idea. |
|
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 ***@***.***> 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 <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAm4bxfzC63qzEo876W7JpGPwl-jeLPWks5rg6qigaJpZM4MN5Ke>.
|
|
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? |
|
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 ***@***.***> 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 <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAm4b4-mHP2jjvOohiWxGHYa7p1QzYfGks5rg9RWgaJpZM4MN5Ke>.
|
|
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. |
|
libotp
… On Feb 28, 2017, at 12:14 AM, Mark Bao ***@***.***> 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 <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAm4b5aJWRjdPq_jHhm_OmNyttTvzxX0ks5rg9dqgaJpZM4MN5Ke>.
|
|
I am not proficient in OO JS and not sure what inheritance pattern is. |
|
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 ***@***.***> 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 Would you be interested in taking the lead for |
|
@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 |
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.
HOTPandTOTP.The text was updated successfully, but these errors were encountered: