Difference between revisions of "Features/Sugar Update Control ASLO"
(→Scope) |
m (update information) |
||
Line 2: | Line 2: | ||
== Summary == | == Summary == | ||
− | Modify the existing Sugar Update Control to pull from | + | Modify the existing Sugar Update Control to pull from activities.sugarlabs.org |
== Owner == | == Owner == | ||
Line 13: | Line 13: | ||
== Current status == | == Current status == | ||
* Targeted release: .86 | * Targeted release: .86 | ||
− | * Last updated: | + | * Last updated: 30 July 2009 |
− | * Percentage of completion: | + | * Percentage of completion: 75% All basic functionality is present. Needs testing. |
== Source == | == Source == | ||
− | + | http://git.sugarlabs.org/projects/update | |
− | http://git.sugarlabs.org/projects/ | ||
== Detailed Description == | == Detailed Description == | ||
− | + | Update enables users to update their installed activities from the Activities Library at activities.sugarlabs.org. Activities.sugarlabs.org is base on the well established addons.mozilla.org. | |
Using ASLO the client can request information about updated by sending a url of the form | Using ASLO the client can request information about updated by sending a url of the form | ||
Line 57: | Line 56: | ||
== Benefit to Sugar == | == Benefit to Sugar == | ||
− | This benefits Sugar by moving the entire activities infrastructure to | + | 1. This benefits Sugar by moving the entire activities infrastructure to activities.sugarlabs.org rather than being spread across a wiki and aslo. |
− | It reduces activity developer work load. | + | 2. It reduces activity developer work load by using the established activites.sugarlabs.org upload process to update activities. |
− | It reduces and isolates infrastructure load between wiki, | + | 3. It reduces and isolates infrastructure load between wiki, activities.sl.o, and download system. |
− | + | a. ASLO provides all necessary update information in a single network transaction. | |
− | + | b. ASLO is backed by memcache, so standard update pings are very cheap. | |
− | + | c. ASLO can be configured to store and serve downloads from download-farm to ease scaling issues. | |
== Scope == | == Scope == | ||
− | Technically the scope is | + | Technically the scope is limited. Most of the changes are inside sugar-update-control or are in ASLO. |
There will not be external api changes. | There will not be external api changes. | ||
− | + | Over the last several months, ASLO has been improving and proving it's reliability. Many activities are being served via ASLO as their information is marked deprecated on wiki.laptop.org. Shifting update to point to also will require clear communication to end users and developers. | |
− | |||
− | |||
=== Implementation === | === Implementation === |
Revision as of 17:11, 14 August 2009
Summary
Modify the existing Sugar Update Control to pull from activities.sugarlabs.org
Owner
This should link to your home wiki page so we know who you are
- Name: David Farning
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: <dfarning@sugarlabs.org>
Current status
- Targeted release: .86
- Last updated: 30 July 2009
- Percentage of completion: 75% All basic functionality is present. Needs testing.
Source
http://git.sugarlabs.org/projects/update
Detailed Description
Update enables users to update their installed activities from the Activities Library at activities.sugarlabs.org. Activities.sugarlabs.org is base on the well established addons.mozilla.org.
Using ASLO the client can request information about updated by sending a url of the form
http://activities.sugarlabs.org/services/update.php?id=org.laptop.WebActivity&appVersion=0.82
ASLO responds by returning XML of the form
<?xml version="1.0" encoding="UTF-8"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#"><RDF:Description about="urn:mozilla:extension:org.laptop.WebActivity"> <em:updates> <RDF:Seq> <RDF:li resource="urn:mozilla:extension:org.laptop.WebActivity:102"/> </RDF:Seq> </em:updates> </RDF:Description>
<RDF:Description about="urn:mozilla:extension:org.laptop.WebActivity:102"> <em:version>102</em:version> <em:targetApplication> <RDF:Description> <em:id>{3ca105e0-2280-4897-99a0-c277d1b733d2}</em:id> <em:minVersion>0.82</em:minVersion> <em:maxVersion>0.82</em:maxVersion> <em:updateLink>http://activities.sugarlabs.org/downloads/file/26063/browse-102.xo</em:updateLink> <em:updateInfoURL>http://activities.sugarlabs.org/versions/updateInfo/29040/%APP_LOCALE%/</em:updateInfoURL> <em:updateHash>sha256:d06c16a1c106dbd1a706f322d75a143d0b4e32815c22f3d95589de83e5480365</em:updateHash> </RDF:Description> </em:targetApplication> </RDF:Description></RDF:RDF>
Benefit to Sugar
1. This benefits Sugar by moving the entire activities infrastructure to activities.sugarlabs.org rather than being spread across a wiki and aslo.
2. It reduces activity developer work load by using the established activites.sugarlabs.org upload process to update activities.
3. It reduces and isolates infrastructure load between wiki, activities.sl.o, and download system.
a. ASLO provides all necessary update information in a single network transaction. b. ASLO is backed by memcache, so standard update pings are very cheap. c. ASLO can be configured to store and serve downloads from download-farm to ease scaling issues.
Scope
Technically the scope is limited. Most of the changes are inside sugar-update-control or are in ASLO.
There will not be external api changes.
Over the last several months, ASLO has been improving and proving it's reliability. Many activities are being served via ASLO as their information is marked deprecated on wiki.laptop.org. Shifting update to point to also will require clear communication to end users and developers.
Implementation
How To Test
Click on M Settings -> Software update.
Visually verify the "From Version XXX to XXX" is correct for your system.
NOTE: the updater currently reports information on all activities, not just the ones with valid updates. This is for debug purposes.
User Experience
Nothing should change from user point of view.
Dependencies
None
Contingency Plan
None necessary, revert to previous release behaviour.
Documentation
None
Release Notes
None yet
Comments and Discussion
You can add categories to tie features back to real deployments/schools requesting them, for example [[Category:Features requested by School Xyz]]