W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [widgets] ETags and Automatic updates

From: mike amundsen <mca@amundsen.com>
Date: Wed, 2 Jul 2008 03:48:37 -0400
Message-ID: <b548df650807020048i3542d910p79b65159ac3ae3d1@mail.gmail.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: "Web Applications Working Group WG" <public-webapps@w3.org>

While "ETag" is the name of an HTTP Header, the _contents_ of the ETag
has nothing to do with HTTP.

No matter the delivery format, a hash value that represents the widget
can be supplied. It can be done as an HTTP Header, as an attribute in
the XML that represents the widget (as in your example), Or as some
other element delivered in the package itself.

Mike Amundsen

On Wed, Jul 2, 2008 at 2:21 AM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>
> It was previously suggested that we use ETags as a way of managing
> widget updates. The idea was that we would include and ETag attribute
> in the <update> element:
>
> <widget>
>  <update etag="?????" url="http://bla.com/updates/my.wgt">
> </widget>
>
> The problem is that it's impossible for the widget author to know what
> the ETag for a widget is going to be until the widget is served over
> HTTP (unless they know how to set it themselves somehow on the server
> - which I personally have no idea how to do). So, once the author gets
> the etag, modifies the <update> element, and then puts the widget back
> on the server, the server will again change the ETag! and so it goes
> ad infinitum.
>
> This problem arises because users can acquire a widget from sources
> other than HTTP (e.g. BlueTooth, local storage, etc.), and so we don't
> initially have access to any of the usual HTTP headers for cache
> control.
>
> Can anyone see a way around this problem using HTTP?
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>



-- 
mca
http://amundsen.com/blog/
Received on Wednesday, 2 July 2008 07:49:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT