Re: [Widgets 1.0] Automatic Updates (1.0)?

You shouldn't need to extend HTTP at all for this use case; use the  
URI, look at the ETag, Last-Modified, If-None-Match and If-Modified- 
Since headers, along with the 304 response. Also, please recommend  
that responses be cacheable for some reasonable amount of time (e.g.,  
Cache-Control: max-age=3600).

Also, is the indirection of a manifest really necessary? Why not just  
have them periodically poll the archive of the widget itself?

On 2007/08/24, at 4:42 PM, Marcos Caceres wrote:

>
> 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
>

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Thursday, 30 August 2007 03:22:08 UTC