[Widgets 1.0] Automatic Updates (1.0)?

Hi All,
On the last day of WAF face 2 face meeting in Oslo, a few of us
started discussing a model for doing automatic updates of widgets.
>From that discussion, I have written up a usage example (below).

Personally, I am seeking feedback as to whether this model is any
good? And if the model could be applied more universally as a way of
doing automated updates of locally stored resources (hence, an
"Automatic Updates 1.0" specification)? or should it just be limited
to widgets?

The model is loosely based on Firefox's addon's updates, and Yahoo!'s
Widget Engines updates model [1].

Security note: although the following example is done over HTTP, any
specification would recommend that automatic updates of resources are
always done over HTTPS (for obvious reasons).

Usage Example
-----------------------
Assume a UA wants to check if it has the latest version of a local
resource foo.zip. The UA has locally stored three pieces of
information about the resource:

   1. The version of the resource: 1.0.
   2. An identifying string for the resources:
7c69b448-514d-11dc-8314-0800200c9a66. In this instance, the
identifying string is a UUID but it could also be a URI or anything.
   3. An update URI: http://example.com/versionChecker.php

With these three pieces of information, the UA is able to negotiate
the latest version of foo.zip with http://example.com by following
three steps:

   1. The UA sends a GET request to the update URI. As part of the
HTTP request, the UA includes an Resource-Identifier header and an
optional Resource-Version header as part of the HTTP request header.
The request from the UA would look like:

Get /versionChecker.php HTTP/1.1
Host: example.com
Accept: text/xml
Resource-Version: 1.0
Resource-Identifier: 7c69b448-514d-11dc-8314-0800200c9a66

   2. The server receives the request and possibly checks a database,
table, or list for the next available resource that matches value of
the Resource-Identifier header. If there is no new version, the server
sends back HTTP response code 204 No Content, which indicates no new
resource is available.

   3. If a new version of the resource is available, or the user agent
did not send the Resource-Version request header, then the server
sends back the relevant update details (see example below).

<?xml version="1.0" encoding="utf-8"?>
<update
  id="7c69b448-514d-11dc-8314-0800200c9a66"
  src="http://example.com/foo.zip?lang=en&platform=win"
  version="1.1.0.1"
  bytes="1024">
      <description>We fixed some bugs and added some new APIs!</description>
      <hash type="MD5">c1bcf9317ba200daeb7d64dc55c97fe95e02ab87</hash>
</update>

   4. From the DOM deduced from the update details, the UA can derive:
          * If the original Resource-Identifier matches the update
element's id attribute. If the two values don't match, then the update
process must terminate.
          * The URI from where the updated resource can be aquired.
          * The version to which the resource will be changed to (ie.
from 1.0 to 1.1.0.1).
          * The size in bytes of the update resource addressed by
update element's src attribute (optional). On a mobile device, the UA
could, for example, inform the user of the number of bytes that need
to be downloaded in order to perform the update.
          * A description of what has been updated or otherwise
changed (optional).
          * An hash digest of the resource pointed to by the src
attribute (optional) and, the type attribute, which hashing algorithm
was used (Optional).

   5. If the UA is instructed by the end-user or by automatic means to
proceed with the update, the UA downloads the resource from the URI
given by the update element's src attribute and stores it locally
without overwritting the original resource.

   6. If the update details contained a hash element with a valid hash
value, then the UA can derive the hash value for the updated resource
using the method specified by the hash element's type attribute
(possible types are "SHA-1" or "MD5", UA assumes MD5 if type element
is missing). The UA then performs a hash check. If the values don't
match, the UA may ask the the end-user how to proceed (ie. discard the
update resource or try again?)

   7. The UA overwrittes the original resource with the updated
resource. The UA takes the
appropriate action based on the application type. For example, the
application is restarted or the UA asks the end user to restart the
application, or the particular updated resource is dynamically
reloaded.

Kind regards,
Marcos
[1] http://widgets.yahoo.net/blog/?p=27

-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 24 August 2007 06:42:54 UTC