Lots of nice feedback from my last post, so here’s some new stuff. Up now is downloading new metadata and updates in plugins.
The plugin loader supports a gs_plugin_refresh() vfunc that is called in various situations. To ensure plugins have the minimum required metadata on disk it is called at startup, but with a cache age of infinite. This basically means the plugin must just ensure that any data exists no matter what the age.
Usually once per day, we’ll call gs_plugin_refresh() but with the correct cache age set (typically a little over 24 hours) which allows the plugin to download new metadata or payload files from remote servers. The gs_utils_get_file_age() utility helper can help you work out the cache age of file, or the plugin can handle it some other way.
For the Flatpak plugin we just make sure the AppStream metadata exists at startup, which allows us to show search results in the UI. If the metadata did not exist (e.g. if the user had added a remote using the commandline without gnome-software running) then we would show a loading screen with a progress bar before showing the main UI. On fast connections we should only show that for a couple of seconds, but it’s a good idea to try any avoid that if at all possible in the plugin.
Once per day the gs_plugin_refresh() method is called again, but this time with GS_PLUGIN_REFRESH_FLAGS_PAYLOAD set. This is where the Flatpak plugin would download any ostree trees (but not doing the deloy step) so that the applications can be updated live in the details panel without having to wait for the download to complete. In a similar way, the fwupd plugin downloads the tiny LVFS metadata with GS_PLUGIN_REFRESH_FLAGS_METADATA and then downloads the large firmware files themselves only when the GS_PLUGIN_REFRESH_FLAGS_PAYLOAD flag is set.
If the @app parameter is set for gs_plugin_download_file() then the progress of the download is automatically proxied to the UI elements associated with the application, for instance the install button would show a progress bar in the various different places in the UI. For a refresh there’s no relevant GsApp to use, so we’ll leave it NULL which means something is happening globally which the UI can handle how it wants, for instance showing a loading page at startup.
gboolean
gs_plugin_refresh (GsPlugin *plugin,
guint cache_age,
GsPluginRefreshFlags flags,
GCancellable *cancellable,
GError **error)
{
const gchar *metadata_fn = "/var/cache/example/metadata.xml";
const gchar *metadata_url = "http://www.example.com/new.xml";
/* this is called at startup and once per day */
if (flags & GS_PLUGIN_REFRESH_FLAGS_METADATA) {
g_autoptr(GFile) file = g_file_new_for_path (metadata_fn);
/* is the metadata missing or too old */
if (gs_utils_get_file_age (file) > cache_age) {
if (!gs_plugin_download_file (plugin,
NULL,
metadata_url,
metadata_fn,
cancellable,
error)) {
/* it's okay to fail here */
return FALSE;
}
g_debug ("successfully downloaded new metadata");
}
}
/* this is called when the session is idle */
if ((flags & GS_PLUGIN_REFRESH_FLAGS_PAYLOAD) == 0) {
// FIXME: download any required updates now
}
return TRUE;
}
Note, if the downloading fails it’s okay to return FALSE; the plugin loader continues to run all plugins and just logs an error to the console. We’ll be calling into gs_plugin_refresh() again in only a few hours, so there’s no need to bother the user. For actions like gs_plugin_app_install we also do the same thing, but we also save the error on the GsApp itself so that the UI is free to handle that how it wants, for instance showing a GtkDialog window for example.
