W3C home > Mailing lists > Public > public-appformats@w3.org > September 2007

Re: [ ACTION-107] Updating version list identifier algorithm

From: Mark Baker <distobj@acm.org>
Date: Wed, 19 Sep 2007 14:15:03 -0400
Message-ID: <e9dffd640709191115n419583act3affd103374c3214@mail.gmail.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: "Ian Hickson" <ian@hixie.ch>, "Arve Bersvendsen" <arveb@opera.com>, "Arthur Barstow" <art.barstow@nokia.com>, public-appformats@w3.org

On 9/19/07, Marcos Caceres <marcosscaceres@gmail.com> wrote:
> > Stick with etags.  They work, and the tooling support is already
> > pretty good.  No need to have a widget-specific mechanism when a
> > generic one gets the job done.
> But what if the UA does not have an etag for the resource as it was
> not acquired over HTTP? For example, you gave me the widget on a CD or
> sent it to me as an email attachment. Are you saying that the version
> should be the etag?

You could do it the other way around; make the etag the version.  But
as Ian noted, it would opaque, so the client wouldn't be able to do
version-y things to it, like check if it were greater or less than a
previous value.

> Eg. config.xml:
> <widget version="ImReallyAnETagdsfafddsa2" />
> I'm not really following....

I'm saying that version information isn't needed.  It can be treated
as an implementation detail because what it means isn't exposed to a

If I were doing this, my root element might look like;

<widget src="http://example.org/widget/foo.widget" />

Then even if I get the widget from a CD, I still have its URI and
etag, so can open an HTTP connection to example.org and download the
latest version.  You could also add an "etag" attribute there, but
that would just be an optimization as it would allow the server to
return 304 if you've got the latest version.

But that's just me 8-)

Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Wednesday, 19 September 2007 18:15:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC