visual feedback when library update is done

[Notmarrco]

After launching a library update there's no way to know if the update is still running or not, unless by looking in the server logs :) Priority very low though ^^

[devsnd]

I consider the priority not too low, actually: It is possible to launch multiple updates fromt he webinterface and therefore locking up the server...

my proposition would be to write the server state inside the pid file... I don't know if there is anythong else to consider, but this would be quite reasonable i guess.

[tilboerner]

From a UX standpoint, it would be neat to disable the update button and display a busy animation. A progress indicator would be even better, but I'm not sure the current estimation algorithm is good enough. (The update call could theoretically return a progress object that can be polled, but I'm getting ahead of things here.)

Using the pid file to hold the state is probably fine, but it seems a bit messy to me: Neither the httphandler nor the updater should know about the pid file, in my opinion. Ideally we'd have a separate updater object to handle this locking business (I guess?), but let's not refactor or further complicate the sqlitcache module right now. ^^

(I guess I would also argue that a running update is not so much a server state, but rather the state of an auxiliary, not core, function. The server itself can run with or without the update thing, and updates don't require a running server.)

Since the main purpose is to prevent multiple updates being triggered from the UI, I suggest building a locking mechanism into the relevant API call. httphandler is in effect a singleton, so it can keep related server-wide state. (cherrymodel would work as well, but is no better solution, for all the same reasons.) Wrap the call to the updater inside a try ... finally mechanism (context manager?) to guard and set the state, and we should have a crude, but working solution that doesn't use too much outside knowledge.

[6arms1leg]

i totally agree with @tilboerner. :+1: :heart_eyes_cat:

[tilboerner]

A restful approach could involve a resource collection called something appropriate like updates. POSTing to it would create a resource representing the update, or result in an error. GETting a collection index reveals if an update is running. This can be expanded quite neatly, if needed. Ideally, the file database backend would conform to this process in a more natural way. In the meantime, we could extend the httphandler API and the frontend with this development in mind:

UI

• [ ] on click: call API, schedule callback
• [ ] callback:
  • success ( = update triggered, analog HTTP status 201 Created ): "update started", schedule some handler function,
  • not quite (= already updating, analog 303 See other): "update already in progress", schedule same handler,
  • error (= your bad or my bad, analog 4xx 5xx errors): "this went badly"
• [ ] handler: disable button and show some text "update in progress", while API says update is running; then notify update is done

API

• [ ] thread-safe mechanism to query & set flag for update in progress (solution can be local to API only)
• [ ] new API call checks if update running
• [ ] existing API call feeds response to UI callback as above

Too elaborate?