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

On Fri, 24 Aug 2007 08:42:47 +0200, Marcos Caceres  
<marcosscaceres@gmail.com> wrote:

>    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

The use of an extra HTTP header to identify the actual resource seems to  
be outside of what is recommended in the TAG finding "URIs,  
Addressability, and the use of HTTP GET and POST", <URL:http:// 
www.w3.org/2001/tag/doc/whenToUseGet.html>, points 1.2 and 2. I would much  
prefer that the only request header kept is the optional resource version  
header.

Someone working within a "one script to check them all" could still code  
this into his update uri using query strings:

GET /versionChecker?identifer=7c69b448-514d-11dc-8314-0800200c9a66

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

The specifics of the format would need to be addressed separately, but a  
few comments:

* A resource may, e.g. for the purpose of mirroring, be represented by  
multiple URI's:
   <updatelocation href="http://no.example.com/foo.wgt" />
   <updatelocation href="http://us.example.com/foo.wgt" />
   <updatelocation href="http://example.cn/foo.wgt" />
* Updated widgets (or other resoruces where this update scheme applies,  
for that matter), may require that settings are altered (such as a widget  
that previously didn't require network access will require it in the  
updated version). Depending on settings and policies, this may leave the  
widget in an unworkable state after update.

How do we handle these issues?


-- 
Arve Bersvendsen

Developer, Opera Software ASA
http://www.opera.com/

Received on Tuesday, 28 August 2007 12:38:32 UTC