On Fri, 24 Aug 2007 08:42:47 +0200, Marcos Caceres
<[EMAIL PROTECTED]> 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/
