#393 notify when background jobs' status changes

[Lee Worden]

In 1.19+, WW is now polling the server every 60 seconds for relevant background job info, and updating the displayed list of jobs (including in the trivial case in which there are currently no jobs).

Along with quietly updating the list, it would be great to have a pop-up notification when a job finishes. And when a job is created by someone else. (We already have one when you create or kill a job.)

[Lee Worden]

• Caching on the server side to reduce the workload, i.e. it should only census all the background directories, query SGE, etc once a minute, not every time someone asks for an update. This will be important when upgraded wikis are in wider use. Fortunately, not too hard to do, it's already generating the information in the right form, just write it into a file and don't redo it until the file's old enough.

This part is done. Removing from the ticket's description.

[Lee Worden]

As for the popup part, the situation's kind of like this, I think: currently, the server-side php code retrieves, caches, and interprets the list of current and past background jobs, and provides a fully-formatted html box to the client. Every 60 seconds, the client sends an api request, and gets a new, updated html box.

This makes it hard for the client to detect whether a given job has appeared, finished, etc. To make it easy, and to improve the code design in general, I would prefer the server to provide a lower-level data structure summarizing the list of background jobs, and the client to interpret and format it.

I think this requires duplicating the formatting logic in both php and js, since the server provides the initial jobs list as part of the page's HTML, and then the client would be providing later updates to it. The initial one is there because I want non-JS browsers to have a list of jobs (it won't update on those browsers, of course).

That double-formatting should be okay, because MW provides a clean way to do message formatting that works in both php and js.

Making that change would let me fix another bug as well, which is that when you do multiple actions in the jobs list at the same time - which is fine and desirable - it works fine except that when the first request finishes, it loads an updated jobs list, and the other requests' spinners get erased. When the js has access to the underlying data structure, I should be able to update and preserve the active spinners.

[Lee Worden]

I think piling multiple issues into a single ticket is confusing, and I want to do it less. So I'm putting the spinner thing at [#470], with a link back to here. I'll also edit this ticket's description so it's clearly only about the popup thing.

[Lee Worden]

It would also be cool to update quicker when a job has just been created, because it's common for a job to fail within a second or two, and we often want to get that feedback right away, without waiting 60 seconds.