- From: Arve Bersvendsen <arveb@opera.com>
- Date: Tue, 28 Aug 2007 14:37:34 +0200
- To: "Marcos Caceres" <marcosscaceres@gmail.com>, "public-appformats@w3.org" <public-appformats@w3.org>
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