2,751
edits
Changes
Jump to navigation
Jump to search
m
Features/Sugar Update Control ASLO (view source)
Revision as of 10:58, 16 July 2009
, 10:58, 16 July 2009create page
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
'''Comments and Explanations:'''
There are comments (in italic) providing guidance to fill out each section, see also [[Features/Policy]]. '''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 ==
Modify the existing Sugar Update Control to pull from ASLO instead of the wiki.laptop.org
== Owner ==
''This should link to your home wiki page so we know who you are''
* Name: [[User:dfarning| 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: 16 July 2009
* Percentage of completion: 50% All basic functionality is present. Needs testing.
== Source ==
http://git.sugarlabs.org/projects/sugar-update-control/repos/aslo-clone
== Detailed Description ==
Current, the Sugar Update Control pulls from wiki.laptop.org. Server side, this results in unnecessary work for activities developers as they must update specific wiki pages when releasing new activities. The existing system is rather fragile as developers must store the update information by hand in machine-readable micro-format. FWIW, this system was pretty good until ASLO came along.
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 ==
This benefits Sugar by moving the entire activities infrastructure to aslo rather than being spread across a wiki and aslo.
It reduces activity developer work load.
It reduces and isolates infrastructure load between wiki, aslo, and download system. ASLO is backed by memcache, so standard update pings are _very_ cheap. ASLO can be configured to store and serve downloads from download-farm to ease scaling issues.
Makes activities developers and infrastructure maintainers lives easier.
== Scope ==
Technically the scope is pretty limited. Most of the changes are inside sugar-update-control or are in ASLO.
There will not be external api changes.
Depends on the bitfrost python modules. Until a decision is made concerning where to include those modules in Sugar, actinfo.py, actutils.py and urlrange.py are shipped with sugar-update-control.
Socially, this is _huge_ change. 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.
== 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 ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
[[Category:Feature Page Incomplete]]
[[Category:Feature]]
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''
'''Comments and Explanations:'''
There are comments (in italic) providing guidance to fill out each section, see also [[Features/Policy]]. '''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 ==
Modify the existing Sugar Update Control to pull from ASLO instead of the wiki.laptop.org
== Owner ==
''This should link to your home wiki page so we know who you are''
* Name: [[User:dfarning| 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: 16 July 2009
* Percentage of completion: 50% All basic functionality is present. Needs testing.
== Source ==
http://git.sugarlabs.org/projects/sugar-update-control/repos/aslo-clone
== Detailed Description ==
Current, the Sugar Update Control pulls from wiki.laptop.org. Server side, this results in unnecessary work for activities developers as they must update specific wiki pages when releasing new activities. The existing system is rather fragile as developers must store the update information by hand in machine-readable micro-format. FWIW, this system was pretty good until ASLO came along.
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 ==
This benefits Sugar by moving the entire activities infrastructure to aslo rather than being spread across a wiki and aslo.
It reduces activity developer work load.
It reduces and isolates infrastructure load between wiki, aslo, and download system. ASLO is backed by memcache, so standard update pings are _very_ cheap. ASLO can be configured to store and serve downloads from download-farm to ease scaling issues.
Makes activities developers and infrastructure maintainers lives easier.
== Scope ==
Technically the scope is pretty limited. Most of the changes are inside sugar-update-control or are in ASLO.
There will not be external api changes.
Depends on the bitfrost python modules. Until a decision is made concerning where to include those modules in Sugar, actinfo.py, actutils.py and urlrange.py are shipped with sugar-update-control.
Socially, this is _huge_ change. 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.
== 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 ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
[[Category:Feature Page Incomplete]]
[[Category:Feature]]
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''