[Chandler-dev] Automatically checking for updates to Chandler Desktop

[Grant Baillie]

So, today I landed the fix to Bug 603, the "automatically check for  
updates" feature in Chandler Desktop. Here's a long and rambly outline  
of what I did, hopefully going from more user-centric to more  
developer-centric. Comments, suggestions and questions welcome, of  
course.

- By default, Chandler will now check once a week if there are new  
updates available. There's a "Check for Updates" menu (under "File" on  
the Mac, "Help" on Windows/Linux), with the entries:

    Now (checks right away)

    Daily
    Weekly
    Don't Check Automatically

One of the last three have a checkmark ("Weekly" by default).

- The original bug requested that the menu go in the application menu  
on the Mac. Sadly, to the best of my knowledge this menu is not  
accessible via wx, so I had to stick it in the File menu.

- Using "Now" gives you one of 3 possible dialogs:
    - An error dialog (e.g. server unreachable)
    - A message telling you your Chandler is up-to-date.
    - A dialog telling you about a new update. For a mock-up, see the  
mockup [1]

- For help in testing, I added a Tools -> Check for Test Updates menu  
item, that points off to a different URL on our build machine. This is  
handy if you want to see the dialog, but the plan also is to use this  
for pre-release testing.

- The new code mostly lives in the module osaf.app.updates (see [2]).  
The data is stored in microformat-style XHTML, as I proposed in [3],  
and is downloaded via HTTP fromdownloads.osafoundation.org. (If you  
have an HTTP proxy configured in Chandler, we'll use that, too).

- There is a comment in the bug from Heikki that the download data  
should be retrieved via https. There are no technical reasons on the  
client side not to do this (although I'm not sure which servers we  
have that run https). However, it seems to me that if we're  
downloading the entire application via http, it makes no sense to  
secure the download URL by encrypting the update information if the  
download itself is unsecured.

- We also use Chandler Desktop's standard User-Agent string, so I  
believe that should allow us to compile metrics on when people are  
checking for updates. However, not knowing how such metrics are  
actually compiled, someone like Jared should probably check that it is  
indeed possible to do this.

- The current information (for 0.7.5.1) has been embedded in the page <http://downloads.osafoundation.org/download 
 > via a Twiki %INCLUDE%. This means that it's possible to update the  
downloads page via a script at the end of the release process (rather  
than editing the Wiki by hand, which is a little error-prone right  
now). I have been working on some tools to update various sites during  
build/release, and intend to test these during the next Chandler  
Desktop release.

- For comparing version strings, we defer to setuptools's  
package_resources.parse_version() API. So far as I know, this works  
correctly for the various version strings Chandler uses (i.e. for  
release and checkpoint  builds, as well as 'make install' svn  
checkouts), but if anyone knows of exceptions, let me know.

- Very schematically, we look for stuff like the following in the XML  
we download:

<... class="release-info"">
   <... class="release-version">VERSION</...>
   <... href="DOWNLOAD-URL" class="download-PLATFORM">
   <... class="release-new-features">new feature(s) text
   <... href="..." class="announcement-url">

Here:

  "<..." == HTML elements (in practice, some of them have  
style="display:none" so that they're invisible in the downloads page).
VERSION == a version string, like "0.7.5.1", or "0.7.6.dev-r16367"
DOWNLOAD-URL == the URL we will open in your browser (if it matches  
your browser).
PLATFORM == a string we will use to match Chandler desktop to download  
URL.

The platform matching code tries to match the "platform ID" and "OS  
ID" contained in Chandler's Utility.py as much as it can. (There are  
corresponding unit tests for said matching). This means that  
currently, we can automatically point you at the correct Mac download  
(i.e. ppc, or intel or intel Leopard), and have all windows machinse  
download a single .exe. However, if in the future we had a separate  
Vista build, we could add that to the update data file and it should  
Just Work. (Ha!).

[1] <https://bugzilla.osafoundation.org/attachment.cgi?id=5061>
[2] <http://viewcvs.osafoundation.org/chandler/trunk/chandler/parcels/osaf/app/updates.py?rev=16360&view=markup 
 >
[3] <http://lists.osafoundation.org/pipermail/chandler-dev/2008-March/009827.html 
 >