[Feature] Ability to extract files simultaneously

[AlexSmirnov9107]

Fix or Feature to #10

[ryanheise]

Going forward, I wonder whether it would be better to generate a unique ID for each instance rather than use the file name. The plan is to eventually include partial results of the waveform data in the progress so that eventually you might not need the file.

[AlexSmirnov9107]

Ok, will change to ID

[ryanheise]

Before you do that, I haven't actually thought it through completely, just thinking out aloud. This may be like a job ID.

[ryanheise]

Just curious, what is the scenario where the second condition is required?

[AlexSmirnov9107]

Sometimes the progress never become 100, kind of rare times. may be frame count cause the problem. Its difficult to find

[ryanheise]

Your condition wouldn't help if the progress never became 100. Maybe you meant that frameCount never becomes 0?

[Faaatman]

This looks great! thank you guys for the great work.
@ryanheise if you think this is resource-intensive what do you think about adding a max number of concurrent jobs so that people could limit the number of files being extracted?
if this PR doesn't get merged, do you think we can at least throw an error if a job tries to run while another one is running?
I myself will be implementing a queue interface but I think an exception thrown is much needed.
I will be happy to help. :)

[ryanheise]

@ryanheise if you think this is resource-intensive what do you think about adding a max number of concurrent jobs so that people could limit the number of files being extracted?

That is something that can/should be implemented by the app. (I like to keep things simple)

if this PR doesn't get merged, do you think we can at least throw an error if a job tries to run while another one is running? I myself will be implementing a queue interface but I think an exception thrown is much needed. I will be happy to help. :)

At this stage my plan is to eventually merge this PR.

Before I do that, I'm just thinking about whether we want to have a unique ID for each instance generated by uuid or just use the file path as the unique ID. (Again just thinking of simplicity.)

[Faaatman]

Before I do that, I'm just thinking about whether we want to have a unique ID for each instance generated by uuid or just use the file path as the unique ID. (Again just thinking of simplicity.)

I think we should avoid the path because of duplication. If the same widget is rendered twice this would cause an error. Where using uuid even if there are duplicates the waveform would be extracted.

[ryanheise]

I would consider it a misuse of the plugin to simultaneously write to the same path, so the path should be unique among the simultaneous requests.

[Faaatman]

I would consider it a misuse of the plugin to simultaneously write to the same path, so the path should be unique among the simultaneous requests.

It is a misuse, but I still think UUID would be the better approach since it's not prone to as many problems as the path approach down the line. And it would stop people from opening issues when they misuse the plugin, instead, it would just make their apps a little bit slower.

[ryanheise]

This problem is not a a real problem since it can be documented and an exception can be thrown if the same output file is being used in two simultaneous requests. You mentioned there are more problems, though?

[ryanheise]

I'll add to the above that using a UUID does not actually solve the problem of using the same output file in simultaneous requests - an exception would be needed.

[ryanheise]

This PR has now been merged and released, and I have done some minor cleanup and removed the uuid key in favour of the output filename. Thanks, @AlexSmirnov9107 for the contribution.