Prevent too much workload on synchronous XMLhttprequest

[blueCat11]

On localhost we simply get a warning like this: "Synchrone XMLHttpRequests am Haupt-Thread sollte nicht mehr verwendet werden, weil es nachteilige Effekte für das Erlebnis der Endbenutzer hat. Für weitere Hilfe siehe http://xhr.spec.whatwg.org/" But on the deployed version, workers are timed out after a set time, and then our music does not render at all. This is for individual analysis. In the case of distant hearing: A similiar problem arises also leading to a timeout in the deployed version, when the analysis takes too long in the backend.

We need to find away around the synchronous property of those requests, a way to manipulate the DOM asynchronously.

[blueCat11]

The results of my investigations for individual analysis:

• Webworkers provide the possibility for asynchronous handling of things (tutorial), but they don't have access to the DOM and communications to them need to be json serializable. The opensheetmusicdisplay-object is not json serializable, so we can't send it to a worker, but to construct it, we need access to the DOM to give it a div to render to, so we can't simply construct it inside the worker. further resources on webworkers
• There are external libraries which allow DOM manipulation inside web workers, but I'm not sure if that works out with OSMD.
• There is actually an issue which requests support for webworkers on the OSMD-github, but it hasn't received much traffic. They suggest passing a canvas object instead of a div, but currently, that's not enabled. There's a similar issue for Vexflow.
• I've also searched a lot for asynchronous DOM manipulation, but so far I've come up empty.

[blueCat11]

Distant Hearing is a bit different, since here the problem is not on the frontend, as for individual analysis, but on the backend. I am more optimistic about that.

• Heroku references something called Background Jobs, and there's also a link to a way to do those with python
• Another workaround would be to not do the analysis immediately on hitting the analyse button on the distantChoice view, but rather to render the UI in the frontend and then start an ajax request which gets the analysis data. That way the time intensive stuff happens asynchronously. I hope that the processing of those data in the frontend isn't too intense...

[blueCat11]

I've just tested the distant hearing workaround in deployment. Unfortunately, we still get errors, because of time-out. Probably we are still doing too much work in the frontend, generating all those graphs... We should:

1. reduce the amount of calculations in the front-end (use groups stats provided by backend)
2. maybe use webworkers to asynchronize generation of stats.

[blueCat11]

Probably we also need to optimize the backend - keyword: parallel loops ( map-reduce?)