- From: mike amundsen <mca@amundsen.com>
- Date: Wed, 2 Jul 2008 03:48:37 -0400
- 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 UTC