if jcef app send multiple messages of same action it may happen that the second message will process fast and return a response and then the first message will complete and override the UI.
the proposed solution is:
the plugin will make sure to process messages of same action in the order they arrive to the plugin.
if a message arrives while the plugin still processing a previous message the plugin will do best effort to cancel the previous message so it will not return a response and process the newer message instead.
this solution will be implemented for all messages, although there are some messages that it may in extreme cases cause an undesired effect. for example message like 'open histogram' ,if user clicks very fast on two buttons we want to open two histograms, but the mechanism mentioned above will cancel the first one. open trace is another example.
one way to solve it is to add a flag to every message indicating if its unique, unique messages are messages with same action and same parameters. so get_asset_data is probably unique, but 'open histogram' may be non-unique if it opens different histograms. then the solution above will cancel only unique messages.
another way to check if a message is unique without requiring a flag is by generating a hash from the json, the plugin will generate a hash for each message and cancel older messages that have the same hash.
in any case ,if plugin cancels previous message or not, the response to the jcef app will be sent in the same order the messages arrive so there is no change that older message will override a response on newer message.
This solution may impact performance , if a newer message can be processed fast and an older message is slow, the newer message will wait for the older message to complete, unless the older is canceled of course.
so probably the impact is neglect able, but may impact non-unique messages if we implement them , so two 'open histogram' at the same time , the second message will wait for the first message to complete.
we can also implement it in a way that ordering is guaranteed only for certain messages. so for example 'get_assets_data' will be an ordered message but 'open histogram' not.
if jcef app send multiple messages of same action it may happen that the second message will process fast and return a response and then the first message will complete and override the UI.
the proposed solution is: the plugin will make sure to process messages of same action in the order they arrive to the plugin. if a message arrives while the plugin still processing a previous message the plugin will do best effort to cancel the previous message so it will not return a response and process the newer message instead. this solution will be implemented for all messages, although there are some messages that it may in extreme cases cause an undesired effect. for example message like 'open histogram' ,if user clicks very fast on two buttons we want to open two histograms, but the mechanism mentioned above will cancel the first one. open trace is another example. one way to solve it is to add a flag to every message indicating if its unique, unique messages are messages with same action and same parameters. so get_asset_data is probably unique, but 'open histogram' may be non-unique if it opens different histograms. then the solution above will cancel only unique messages. another way to check if a message is unique without requiring a flag is by generating a hash from the json, the plugin will generate a hash for each message and cancel older messages that have the same hash.
in any case ,if plugin cancels previous message or not, the response to the jcef app will be sent in the same order the messages arrive so there is no change that older message will override a response on newer message.
This solution may impact performance , if a newer message can be processed fast and an older message is slow, the newer message will wait for the older message to complete, unless the older is canceled of course. so probably the impact is neglect able, but may impact non-unique messages if we implement them , so two 'open histogram' at the same time , the second message will wait for the first message to complete.
we can also implement it in a way that ordering is guaranteed only for certain messages. so for example 'get_assets_data' will be an ordered message but 'open histogram' not.