I like the idea to run "kimchi.getCapabilities" only once and use its results later. Those values are very unlikely to change unless there is some server upgrade. But as far as I understand, there is no syncing strategy to make sure the new variable "kimchi.capabilities" will only be read when the function "kimchi.getCapabilities" has been executed successfully. This may lead to an execution error (i.e. "kimchi.capabilities" may still be undefined) or inconsistent values (e.g the host may have QEMU stream capability but if the function "kimchi.getCapabilities" hasn't finished executing yet, "kimchi.capabilities.qemu_stream" might still have its default value - not the actual one). Also, if the approach is to run "kimchi.getCapabilities" once and then cache its results, we might as well use those cached values elsewhere in Kimchi. The tab "Host" will still execute that function. On 08-08-2014 14:15, Aline Manera wrote:
/config/capabilities was requested twice for the templates tab: one request to identify if qemu has spice support and other one to identify if the qemu has ISO streaming support.
Those requests were made right before using the information, causing a delay on UI until get the server response.
For example, for distant servers, while creating a new template the "Remote ISO" option was disabled at the first time and after some time it was enabled. The same behavior was identified while editing a template, as the graphics options blinked to add the spice on it.
To fix it, request /config/capabilities when loading the templates tab to have this information prior to edit or create a new template.
Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>