The topic came up in #sugar today about the process of updating activities that were not shipped with the image (for lack of a better term, "third-party activities"). There are two standard ways:<br><br>1. Join a shared activity that is using a newer version of code than you have
<br>2. You download a .XO from the web and it installs overtop an existing (signed by the same key, etc) activity. You can optionally uninstall that activity from the journal, before doing this.<br><br>The question that came up (#3), is how to distribute updates to these activities in mass instead of having the user be required to go find the latest version and manually compare (push/notify vs. pull). Installin activities will put dated, potentially buggy pieces of code (bitfrost or not, broken features ruin the user experience) on these machines with no good ways of getting at newer, improved versions of that code.
<br><br>What is planned way to solve this? Could we add a field to the activity's metadata file about where hosting server is to check for newer versions of the .xo file? SJ described it on IRC as:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
step 1 : check all known bundle repositories, ask for updates to your installed bundles<br>step 2 : collate the results by flag (importance / type of upgrade)<br>step 3 : confirm signatures for those the user chooses to install
<br></blockquote><br clear="all">Thoughts?<br><br>-- <br>Michael Burns * Student<br>Open Source {Education} Lab