105
edits
Changes
Jump to navigation
Jump to search
Line 56:
Line 56: − + − + − + Line 69:
Line 69: − + Line 86:
Line 86: − To update an individual activity, the activity updater will perform the following steps in this order:+ − # Download new activity bundle to temporary storage − # Delete existing activity − # Install new activity version − This is intended as a compromise between not requiring the amount of disk space needed for two unzipped versions of the activity, and not deleting the existing activity so early that the user is potentially left without the activity for a long time (especially if the download then fails).+ − Activity installation/deinstallation will be done with the Sugar bundle registry API (jarabe.model.bundleregistry). The activity updater will instantiate its own bundle registry object in its own process.+ − Sugar will become aware of these events through the way it already watches the filesystem. Ticket #3707 will be fixed as part of this implementation effort so that this is fully reliable.+
Features/Automatic activity updates (view source)
Revision as of 17:03, 9 August 2012
, 17:03, 9 August 2012→Scope
Upon establishing a network connection, or upon starting with a network connection already established, where the activity updater has been enabled in the configuration, Sugar will examine whether it needs to launch an automatic activity update if the activity-update-urgent flag is set, or if the last update happened beyond a configurable amount of time in the past.
Upon establishing a network connection, or upon starting with a network connection already established, where the activity updater has been enabled in the configuration, Sugar will examine whether it needs to launch an automatic activity update if the activity-update-urgent flag is set, or if the last update happened beyond a configurable amount of time in the past.
The activity-update-urgent flag is set based on the presence of the file XXX.
The activity-update-urgent flag is set based on the presence of the file <tt>~/.sugar/default/activity_update_urgent</tt>.
When an update successfully completes, the update time is recorded in the gconf key XXX. The amount of time that passes before an automatic activity update is executed is defined by the gconf key XXX, units in days, default 7, zero means no periodic update.
When an update successfully completes, the update time is recorded in the gconf key <tt>/desktop/sugar/update/last_activity_update</tt>. The amount of time that passes before an automatic activity update is executed is defined by the gconf key <tt>/desktop/sugar/update/auto_update_frequency</tt>, units in days, default 0 (which means no periodic update).
The activity updater will be enabled in the boolean gconf key XXX (disabled by default). The gconf key XXX will specify which update mechanism to use (ASLO or microformat), and the XXX gconf key will specify the base server URI to use.
The gconf key <tt>/desktop/sugar/update/activity_update_mechanism</tt> will specify which update mechanism to use (ASLO or microformat), and the <tt>/desktop/sugar/update/activity_update_uri</tt> gconf key will specify the base server URI to use.
The core of the activity updating code (looking for updates, downloading them, installing them) will be moved to a dbus-activated service on the session bus with name XXX. This service, referred to as activity-updater, will automatically exit after 2 minutes of inactivity when no activity updates are ongoing. It will only allow one activity update to happen at a time. The D-Bus API will have the following methods and signals:
The core of the activity updating code (looking for updates, downloading them, installing them) will be moved to a dbus-activated service on the session bus with name XXX. This service, referred to as activity-updater, will automatically exit after 2 minutes of inactivity when no activity updates are ongoing. It will only allow one activity update to happen at a time. The D-Bus API will have the following methods and signals:
* GetDetails(bundle_id): For a given bundle_id already identified as an update, download and return the activity name (localised) and icon.
* GetDetails(bundle_id): For a given bundle_id already identified as an update, download and return the activity name (localised) and icon.
* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates, perform the activity update process (download, install).
* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates, perform the activity update process (download, install).
* StartAutomaticUpdate(): internally perform QueryUpdates() and then run DoUpdates() on all available updates. Returns immediately.
* StartAutomaticUpdate(): internally perform QueryUpdates() and then run DoUpdates() on all available updates. Returns immediately having kicked off the process internally.
* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity update is started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity is downloading or installing, and the progress parameter indicates the percentage of the download or install.
* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity update is started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity is downloading or installing, and the progress parameter indicates the percentage of the download or install.
When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.
When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.
Activity installation/update will be done with the Sugar bundle registry API (jarabe.model.bundleregistry). The activity updater will instantiate its own bundle registry object in its own process.
Sugar will become aware of these events through the way it already watches the filesystem. Ticket #3707 will be fixed as part of this implementation effort so that this is fully reliable.
== Future possibilities ==
* Improve the bundle registry so that it is accessible over dbus and doesn't need the update service to also create its own registry in memory.
==UI Design==
==UI Design==