allow password libraries to be async

[cmcnulty]

In order to support alternate password generation libraries, it would be nice if the SGP (and the API of supergenpass-lib) provided a mechanism for both asynchronous password generation. This would take the form of two callbacks passed into the options array of the password generator function, a progress callback and a completed callback. I already have the code in my fork, I'll split it off into a pull request whenever I get a chance, if I get an indication that such a pull would be considered.

[chriszarate]

Could you elaborate on the use case? Password generation is synchronous. I don't see the benefit of using a callback when you'll have the password and ready immediately upon execution. Couldn't you just pass a reference to the password generation function to accomplish what you need?

[cmcnulty]

In the case of long-running password generation schemes, such as bcrypt ( https://github.com/dcodeIO/bcrypt.js ) the password generation is generally best handled as an async process because it can take several seconds to generate the password. It's true that most bcrypt javascript libraries include a synchronous option as well, but that just locks the browser until the execution is complete. In terms of SGP, it would basically mean that lines 248-263 of sgp.mobile.js would be incapsulated in their own function, which would take as an argument the completed password.

[cmcnulty]

Alternatively, you could provide allow different function altogether for async which seems to be the way a lot of node packages work, but then you'd need a way to fork the decision of which function to use within the sgp.mobile.js file.

[chriszarate]

Sorry for the silence on this, still trying to wrap my head around it.

So, browsers' JS execution is still single-threaded, right? (Unless you are using Web Workers or something.) If so, what will a async/callback end up doing? Won't it still lock the browser, just a little bit later (and maybe that's enough, to let your UI code finish).

[cmcnulty]

That's a very good question, and I had to search around for the answer myself, I only new that it worked! :) The answer is that, yes, JS execution is single-threaded, however node implements some functionality (which is available via browserify), which allows us to run long running processes without locking the thread. Here's a really great article about it:

http://howtonode.org/understanding-process-next-tick

which includes a chapter entitled "Interleaving execution of a CPU intensive task with other events" which is precisely how you'd want SGP to behave, if someone wanted to use a computation/memory intensive hashing algorithms (such as bcrypt or scrypt) instead of the highly efficient hashing algorithms such as MD5 and SHA.

[denis-sokolov]

It's much simpler than you guys debate. :)

A long-running CPU intensive task in the browser can just pause in the middle and setTimeout(next, 0). The browser then gets a chance to run UI, event handlers, and other code. The CPU intensive task takes slightly longer, but the thread does not lock.

This is definitely a very good point, may we continue debating it on supergenpass-lib#19?

[chriszarate]

Closing as this has been addressed in supergenpass-lib.