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
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
