Difference between revisions of "Features/Optional activity updates"

From Sugar Labs
Jump to navigation Jump to search
Line 20: Line 20:
 
''This proposal is based around the needs of the OLPC project in Australia, but reflects a common need (current or future) of other OLPC implementations as well.''
 
''This proposal is based around the needs of the OLPC project in Australia, but reflects a common need (current or future) of other OLPC implementations as well.''
  
'''The problem:''' Previously, Daniel Drake implemented a mechanism for automatic activities updates. This was of great help for OLPC deployments such as Australia. However, the current mechanism will update (or install) ALL the activities in the updates list. This becomes a problem when not all the activities are intended for automatic updates, ie., when the bundle size is too big for massive automatic installation.
+
'''The problem:''' Previously, Daniel Drake implemented a mechanism for automatic activities updates. This was of great help for OLPC deployments such as Australia. However, the current mechanism will update (or install) ALL the activities in the updates list. This becomes a problem when not all the activities are intended for automatic updates, ie., when the bundle size is too big for massive automatic installation. In the practice deployments do not enable automatic updates because this kind of concerns.
  
The proposed solution is to provide a way to mark activities in the microformat file as "optional". Activities marked as optional will:
+
The proposed solution is to provide a way to mark activities in the microformat file as optional. Activities marked as optional will:
  
 
* Not be updated or installed during automatic updates.
 
* Not be updated or installed during automatic updates.

Revision as of 20:08, 5 August 2014


Summary

Extend microformat updater to be able to mark activities as optional for automatic updates.

Owner

  • Martin Abente Lahaye

Current status

  • Targeted release: 0.104
  • Last updated: 05/08/2014
  • Percentage of completion: 90%

Detailed Description

This proposal is based around the needs of the OLPC project in Australia, but reflects a common need (current or future) of other OLPC implementations as well.

The problem: Previously, Daniel Drake implemented a mechanism for automatic activities updates. This was of great help for OLPC deployments such as Australia. However, the current mechanism will update (or install) ALL the activities in the updates list. This becomes a problem when not all the activities are intended for automatic updates, ie., when the bundle size is too big for massive automatic installation. In the practice deployments do not enable automatic updates because this kind of concerns.

The proposed solution is to provide a way to mark activities in the microformat file as optional. Activities marked as optional will:

  • Not be updated or installed during automatic updates.
  • Not be selected by default in the activities updater UI.

Benefit to Sugar

The flexibility added by this feature will allow many deployments to enable the automatic updater, therefore users will benefit from receiving newer activities automatically.

Scope and implementation

A initial implementation can be found in [1]

  • extend microformat parser to extract a new olpc-activity-optional field.
  • extend BundleUpdate class to support this field so other updater components can access to this information.
  • filter activities that are marked as optional when running in automatic mode.
  • do not select activities marked as optional in the updater UI list.

How to test

Modify your microformat file (in the server, ie., wiki or via [2]) and modify activities entry as follows:

<tr>
<td class="olpc-activity-info">
<span class="olpc-activity-id">net.flossmanuals.LevelActivity</span>
<span class="olpc-activity-version">1</span>
<span class="olpc-activity-url"><a href="http://localhost:8000/some/deeper/path/bundles/level-1.xo">download</a></span>
<span class="olpc-activity-optional">1</span>
</td>
</tr>

User Experience

User experienced is untouched, this feature is backwards compatible.