Because of long lag from update on the repo until the change is reflected on the client, editors do manual purge on the clients, and because of that they complain about the clumsy interface for the purge action. Now editors at the clients will update an element at the repo, then hit purge repeatedly until the page refresh (to get faster updates), then adjust the element at the repo to fix mistakes. This is very slow.

In my opinion the workflow is wrong, and does not support the users actions at all.

If a user has an open view on a client that is using data from the repo, then the update should not be delayed for dispatch but be handled at once. When the client updates, the open view in the browser should get a push notification so it can reload. Whether other updates goes through the dispatch queue is of no consequence, most likely nobody are waiting for them anyhow.

This can also be implemented by polling from the client, and checking the revision id, and trigging a purge if it is updated, but that creates much more load on the repo. It can although be implemented as a gadget.

Which browsers to reload can be updated by onload/onunload, and also be kept on a very short list spanning just a few minutes.

Note that the reload should only happen in the view mode, not in edit mode. Or it could be done in edit mode too, but the implementation is much more involved.