-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Async support #121
Comments
async ? asynchronous API ? async.js ? What do you have in mind ? |
Yep an asynchronous version of the API. I'm for replacing the sync API, So it currently works well for small files Though, if one was to zip 50MB (dependent on client, worse on mobile), the This could further be improved with web workers - with double/quadruple I'm interested in using this library though haven't yet due to this And I understand that this would be quite a large architectural change so On Wednesday, April 23, 2014, David Duponchel
|
I agree with the need of an async API, at least for the CPU heavy tasks. |
Ah great, sounds good :) On Thursday, April 24, 2014, David Duponchel notifications@github.com
|
Just a quick update : On a local branch I've created async getters ( Starting with a zip file (7MB) containing compressed xml files (412MB decompressed) :
Firefox/Chrome take between 4 and 14 seconds to decompress the files and 20 seconds to recompress them without freezing the browser. I'd say it's a good start. |
Awesome sounds good David 👍 On Monday, May 5, 2014, David Duponchel notifications@github.com wrote:
|
I will add to this one the support of streaming : removing the time limit but keeping the memory limit (because JSZip holds everything into memory) won't help a lot. |
This will takes more time than expected, the conversion async -> stream isn't as straightforward as I thought (and streamed zip files break all my unit tests). |
Any sync to async library conversion is a big job - done it a few times myself As for using node streams, id recommend you write your own basic streams implementation. Since all streams are just event emitters that you An idea, you could also make your streams behave synchronously when desired by using a optional setTimeout 0. This way your sync functions could call the new streaming functions only when in sync mode - preventing the need to maintain two versions of each function. Not sure if that's feasible though |
After fighting with/against streams, here is an update.
Now, I agree with @jpillora : I should have started with my own basic stream implementation. The results now. I rewrote a lot of stuff : instead of duplicating every methods (sync vs async), I used synchronous "workers". Each one does one task (convert a chunk, utf8 transformation, deflate, etc) and handles the "how". I have two implementations handling the "when" : one synchronous and one asynchronous. Internal methods use workers, only the public API chooses the sync/async implementation. I still have some work before a pull request : the utf8 encode/decode doesn't split correctly the chunks and the sync/async implementations is still a bit rough. I won't give any time estimate : I've already proven that I'm bad with them :-) Regarding the public API : the sync methods didn't change. It may be a good idea to target a v3 for this, remove the deprecated stuff and rethink some parameters ( |
Hi there. Any updates on this? |
@okv if you want async, put jszip into a webworker. Its better then async. All operations are off the main thread, and the post message method is innately async. |
@Noitidart i'm using it on server side (node.js) and want to use default non-blocking approach for this environment - streams. |
Here is the current state: #195 moved JSZip to async methods (and added stream support) and landed on the branch |
@dduponchel got it, thanks for your detailed explanation |
|
No description provided.
The text was updated successfully, but these errors were encountered: