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

On 8/28/07, Arve Bersvendsen <arveb@opera.com> wrote:
> 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.

I'm OK with that. Resource-Version it is.

So, for example, in a simple use case that would give:

GET /some/app.wgt
Resource-Version: 1.0


> 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

Agreed. However, my feeling is the "one script to check them all" will
be the most most common use case as it's the easiest to code for (eg.
using php or asp or whatever). Configuring a web server to defer
requests on resources if the Resource-Version header is there seems
like bit of pain.

Arve, for the sake of argument, would there be any advantage to
prioritizing Resource-Identifier, over Resource-Version?  eg:

GET /versionChecker?version=1.0
Resource-Identifier: 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?

Would that be handled by the manifest of the widget?


>
> --
> Arve Bersvendsen
>
> Developer, Opera Software ASA
> http://www.opera.com/
>


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

Received on Tuesday, 28 August 2007 12:54:14 UTC