105
edits
Changes
Jump to navigation
Jump to search
Line 2:
Line 2: − <!-- You can add categories to tie features back to real deployments/schools requesting them, for example − [[Category:Features requested by School Xyz|<Feature Name>]] (the |Feature Name option sorts the entry on the category page under the first letter of <Feature Name>). --> − '''Comments and Explanations:'''+ − − There are comments (in italic) providing guidance to fill out each section, see also the [[Features/Policy|Feature Policy Page]] for a more detailed explanation of the new-feature process. '''Copy the source to a ''new page'' named Features/''Your Feature Name'' before making changes! DO NOT EDIT THIS TEMPLATE.''' − − <!-- All fields on this form are required to be accepted. − We also request that you maintain the same order of sections so that all of the feature pages are uniform. --> − − <!-- The actual name of your feature page should look something like: Features/Your Feature Name. This keeps all features in the same namespace --> − == Summary ==+ − ''A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.'' − ''This should link to your home wiki page so we know who you are''+ − − − ''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved'' − * Email: <your email address so we can contact you, invite you to meetings, etc.> Line 31:
Line 17: − + + + + + + + + + + + + + + + + + + + + + + + + − ''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?'' − ''Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.''+ + + + + + + − ''What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Features/Automatic activity updates (view source)
Revision as of 16:45, 9 August 2012
, 16:45, 9 August 2012no edit summary
[[Category:Feature Page Incomplete]]
[[Category:Feature Page Incomplete]]
[[Category:Feature|.]]
[[Category:Feature|.]]
</noinclude>
</noinclude>
== Summary ==
Provide an optional mechanism for automatically and transparently (i.e. in the background) updating activities from a central server.
== Owner ==
== Owner ==
* Daniel Drake
* Name: [[User:AcountName| Your Name]]
== Current status ==
== Current status ==
== Detailed Description ==
== Detailed Description ==
''Expand on the summary, if appropriate. A couple of sentences suffices to explain the goal, but the more details you can provide the better.''
''This proposal is based around the needs of the OLPC project in Nicaragua, but reflects a common need (current or future) of other OLPC implementations that I have visited.''
'''The problem:''' Software updates. Previously, the local foundation visited every school at the end of the academic year and reflashed all the laptops, to provide them with a software update. Now the program has expanded to over 20,000 laptops, that is no longer practical nor affordable.
However, there is still an obvious desire to be able to push software updates to the user base. For the operating system, olpc-update is working well enough: the local team has the infrastructure set up to push OS updates through the school server, and the laptops safely update with no user intervention required. But once the XO reboots into a drastically updated OS version, activities often fail to run due to non-backwards-compatible changes at the system level.
Sugar can be instructed to pop up a "you should update your activities" message, offering three buttons, one of which executes the software update section of the control panel, but this has several problems:
* This message comes up whether or not connectivity is available, but connectivity is definitely required for the process to complete.
* In my experience, this message provokes a random response from the user. We're dealing with young children, and this message is somewhat unexpected anyway (the OS update was automatic and transparent).
* Relying on 20,000 children to all perform this step (only when connectivity is available), which is not even something that occurs very naturally for them, is not something that would bring good results.
* If the activity update process fails (e.g. no connectivity), the message doesn't come back again. But activity updating is something absolutely necessary at this point, so it should not give up so easily.
* It's something that should be automatic.
The proposed solution is to remove this message and adds an automatic software update feature that runs in the background. This would be off by default, but could be enabled by deployers of Sugar via system configuration.
The activity updater would run periodically, by default once per week. However, after a system upgrade, an "activity upgrade urgent" flag would be set, resulting in Sugar trying to update its activities every time connectivity becomes available until an update completes successfully.
The existing activity updater in the control panel will still remain for if/when the user wants to perform a foreground update on-demand.
It is assumed that the user has good connectivity to the activity server. This means that either a good internet connection is generally available, or that the activities are hosted on a local school server. (I envision the latter case to be more useful and common for deployments.)
The activities.sugarlabs.org XML interface used by the existing software update control panel section will remain supported, and support for the OLPC activity microformat will also be added. (I envision the latter case to be more useful and common for deployments.)
== Benefit to Sugar ==
== Benefit to Sugar ==
The long-term problem of Sugar deployers not being able to push automatic system updates that break activity compatibility would be fixed. The Zamora Teran Foundation in Nicaragua will be able to push new software to their users in future.
Other functionalities also become available. For example, currently there is no hands-off way for a Sugar deployer to push a new activity to the existing install-base. But, as this activity update would run automatically once per week, this now becomes easy.
Sugar will gain support for the OLPC activity update microformat which is used in the field.
The "you should update your activities" message, which has been seen as a source of user confusion, will go away.
== Scope ==
== 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.
The activity-update-urgent flag is set based on the presence of the file XXX.
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.
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 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:
* GetStatus(): get the status of the current activity update session (if any). Returns the status code last emitted from the SessionStatus signal, the number of activities that are included in any in-progress update, and the number of activity updates already completed.
* GetCurrentUpdateStatus(): get information about the current activity being updated: its name, download size, a boolean flag indicating whether the download has completed, and a percentage progress indication (of either the download or the installation).
* Cancel(): Cancel the ongoing update session, waiting for a safe point before cancelling (e.g. to avoid aborting halfway through installing an activity). This will return immediately but the cancel will not be complete until indicated by the SessionStatus signal.
* QueryUpdates(): Start a new update session, querying for available activity updates. Returns a list of activities available. Each list entry will have: (bundle_id, URL, download_size, current_installed_version_number, update_version_number).
* 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).
* StartAutomaticUpdate(): internally perform QueryUpdates() and then run DoUpdates() on all available updates. Returns immediately.
* 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 ActivityUpdated(bundle_id, success): Raised when an activity update completes, with the success flag indicating success or failure.
* Signal UpdateCompleted(success): Raised when an update session completes, with a flag indicating whether errors were encountered or not.
* Signal SessionStatus(status): Raised with a code indicating the status of the activity updater.
** 0: inactive
** 1: new session opened, for automatic activity update
** 2: new session opened, updates have been queried
** 3: activity download/installation is in progress
This API is intended for internal use only.
When Sugar wants to launch an automatic activity update, it will make a dbus method call to StartAutomaticUpdate(), which will return immediately having kicked off an activity update inside activity-updater.
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.
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.
==UI Design==
==UI Design==