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

On Tue, 28 Aug 2007 14:54:03 +0200, Marcos Caceres  
<marcosscaceres@gmail.com> wrote:

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

I think we may be misunderstanding each other.  When I talk about the URI,  
I think of the update URI as uniquely identifying the resource, which to  
me reads 'This particular widget, in any version, but not necessarily  
being the widget ID'

...

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

Yes, and I think that would imply that the update document would embed,  
fully, or partially, the manifest file of the widget, instead of repeating  
these elements in a new namespace (and here I'll concede that a namespace  
for the manifest is quite likely needed).

-- 
Arve Bersvendsen

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

Received on Tuesday, 28 August 2007 13:44:49 UTC