On Tue, 28 Aug 2007 14:54:03 +0200, Marcos Caceres
<[EMAIL PROTECTED]> 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/
